Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > size_t problems

Reply
Thread Tools

size_t problems

 
 
pete
Guest
Posts: n/a
 
      08-29-2007
jacob navia wrote:
>
> Richard Tobin wrote:
> > In article <(E-Mail Removed)>,
> > Keith Thompson <(E-Mail Removed)> wrote:
> >
> >> It's better to fix the code. It's even better to write it correctly
> >> in the first place.

> >
> > But int s = sizeof(char *) is not broken, even though sizeof() returns
> > a size_t.
> >
> > -- Richard

>
> If we use size_t everywhere, it is an UNSIGNED quantity.
> This means that comparisons with signed quantities will provoke
> other warnings, etc etc.
>
> int s = strlen(str) is NOT broken.


Maybe the signed quantities should be unsigned?

--
pete
 
Reply With Quote
 
 
 
 
Martin Wells
Guest
Posts: n/a
 
      08-30-2007

jacob navia:

> The problem is, when you have in thousands of places
>
> int s;
>
> // ...
> s = strlen(str) ;
>
> Since strlen returns a size_t, we have a 64 bit result being
> assigned to a 32 bit int.

<snip>
> I do not know how to get out of this problem. Maybe any of you has
> a good idea? How do you solve this when porting to 64 bits?


Assuming that you've a shred of intelligence, I'm led to believe that
you suffer from "int syndrome".

"int syndrome" reminds me of old drivers, the kind of people who
always drive the canonical route somewhere. Even during rush-hour,
even at night when the streets are clear, they always take the same
route. I don't know if you'd call it stubbornness or stupidity. They
lack dynamic-ity.

These drivers remind me of the programmers who are "int" people. The
solution to your boggle is so blatantly oblivious that I'm not even
gonna mention what the solution is.

The real problem is why you feel so indoctrinated into using int,
especially places where you shouldn't be using it.

If you want advice though, I'd say use the appropriate types where
appropriate, and to edit any code that uses types wrongly.

Martin

 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      08-30-2007
jacob navia wrote:
>
> I am trying to compile as much code in 64 bit mode as
> possible to test the 64 bit version of lcc-win.
>
> The problem appears now that size_t is now 64 bits.
>
> Fine. It has to be since there are objects that are more than
> 4GB long. The problem is, when you have in thousands of places
>
> int s;
>
> // ...
> s = strlen(str) ;
>
> Since strlen returns a size_t, we have a 64 bit result being
> assigned to a 32 bit int.
>
> This can be correct, and in 99.9999999999999999999999999%
> of the cases the string will be smaller than 2GB...


Simply define s as a long long or (better) as a size_t.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-30-2007
jacob navia wrote:
> Keith Thompson wrote:
>
>> Why didn't you get the same warnings in 32-bit mode? If int and
>> size_t are both 32 bits, INT_MAX < SIZE_MAX, and there are values
>> of size_t that cannot be stored in an int. If the "narrowing
>> conversion" warning is based on the sizes of the type rather than
>> the ranges, I'd say you've just discovered a compiler bug.

>
> 2GB strings are the most you can get under the windows schema in 32
> bits.
>
>> If you're getting hundreds of warnings, it's because you have
>> hundreds of instances of potential loss of information.

>
> Yes, "*POTENTIALLY*" I could be missing all those strings longer
> than 4GB (!!!). But I do not care about those


That is precisely the sloppy attitude that has led to many bugs.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>


--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-30-2007
jacob navia wrote:
>

.... snip ...
>
> int s = strlen(str) is NOT broken.


Yes it is. How can you guarantee that strlen never returns a value
that exceeds the capacity of an int? However:

size_t s = strlen(str);

is NOT broken, assuming suitable #includes and definitions.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-30-2007
CBFalconer <(E-Mail Removed)> writes:
> jacob navia wrote:
> ... snip ...
>>
>> int s = strlen(str) is NOT broken.

>
> Yes it is. How can you guarantee that strlen never returns a value
> that exceeds the capacity of an int?


By never passing it a pointer to a string longer than INT_MAX
characters. This tends to be easier than, for example, guaranteeing
that 'x + y' will never overflow.

The declaration may or may not be broken, depending on what happens at
run time. The problem is that, apparently, the programmer knows it's
safe, but the compiler doesn't have enough information to prove it.

The ideal solution is to declare s as a size_t, and to make whatever
other code changes follow from that, but that's not always practical.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      08-30-2007
jacob navia wrote:
> Richard Tobin wrote:
>> In article <(E-Mail Removed)>,
>> Keith Thompson <(E-Mail Removed)> wrote:
>>
>>> It's better to fix the code. It's even better to write it correctly
>>> in the first place.

>>
>> But int s = sizeof(char *) is not broken, even though sizeof() returns
>> a size_t.
>>
>> -- Richard

>
> If we use size_t everywhere, it is an UNSIGNED quantity.
> This means that comparisons with signed quantities will provoke
> other warnings, etc etc.
>
> int s = strlen(str) is NOT broken.


Why would you want to assign an unsigned value to an int? Why do you
think it makes sense to have a negative size?

--
Ian Collins.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-30-2007
Keith Thompson wrote:
> CBFalconer <(E-Mail Removed)> writes:
>> jacob navia wrote:
>> ... snip ...
>>>
>>> int s = strlen(str) is NOT broken.

>>
>> Yes it is. How can you guarantee that strlen never returns a value
>> that exceeds the capacity of an int?

>
> By never passing it a pointer to a string longer than INT_MAX
> characters. This tends to be easier than, for example, guaranteeing
> that 'x + y' will never overflow.
>
> The declaration may or may not be broken, depending on what happens at
> run time. The problem is that, apparently, the programmer knows it's
> safe, but the compiler doesn't have enough information to prove it.
>
> The ideal solution is to declare s as a size_t, and to make whatever
> other code changes follow from that, but that's not always practical.


Which I said, and you snipped. Why?

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>


--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      08-30-2007
Ian Collins wrote:
> jacob navia wrote:
>> Richard Tobin wrote:
>>> In article <(E-Mail Removed)>,
>>> Keith Thompson <(E-Mail Removed)> wrote:
>>>
>>>> It's better to fix the code. It's even better to write it correctly
>>>> in the first place.
>>> But int s = sizeof(char *) is not broken, even though sizeof() returns
>>> a size_t.
>>>
>>> -- Richard

>> If we use size_t everywhere, it is an UNSIGNED quantity.
>> This means that comparisons with signed quantities will provoke
>> other warnings, etc etc.
>>
>> int s = strlen(str) is NOT broken.

>
> Why would you want to assign an unsigned value to an int? Why do you
> think it makes sense to have a negative size?
>


Because that int is used in many other contexts later, for instance
comparing it with other integers.
int len = strlen(str);

for (i=0; i<len; i++) {
/// etc
}


The i<len comparison would provoke a warning if len is unsigned...
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      08-30-2007
Martin Wells wrote:
> jacob navia:
>
>> The problem is, when you have in thousands of places
>>
>> int s;
>>
>> // ...
>> s = strlen(str) ;
>>
>> Since strlen returns a size_t, we have a 64 bit result being
>> assigned to a 32 bit int.

> <snip>
>> I do not know how to get out of this problem. Maybe any of you has
>> a good idea? How do you solve this when porting to 64 bits?

>
> Assuming that you've a shred of intelligence, I'm led to believe that
> you suffer from "int syndrome".
>
> "int syndrome" reminds me of old drivers, the kind of people who
> always drive the canonical route somewhere. Even during rush-hour,
> even at night when the streets are clear, they always take the same
> route. I don't know if you'd call it stubbornness or stupidity. They
> lack dynamic-ity.
>
> These drivers remind me of the programmers who are "int" people. The
> solution to your boggle is so blatantly oblivious that I'm not even
> gonna mention what the solution is.
>
> The real problem is why you feel so indoctrinated into using int,
> especially places where you shouldn't be using it.
>
> If you want advice though, I'd say use the appropriate types where
> appropriate, and to edit any code that uses types wrongly.
>
> Martin
>


Assuming that you have a shred of intelligence, you will be able
to understand this:

That int is used in many other contexts later, for instance
comparing it with other integers.
int i,len = strlen(str);

for (i=0; i<len; i++) {
/// etc
}


The i<len comparison would provoke a warning if len is unsigned...

If I make i unsigned too, then its usage within the loop will provoke
even more problems!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
reinterpret_cast<std::size_t>(p) and reinterpret_cast<std::size_t&>() Alex Vinokur C++ 1 02-06-2011 07:48 AM
Casting from const pair<const unsigned char*, size_t>* to constpair<unsigned char*, size_t>* Alex Vinokur C++ 9 10-13-2008 05:05 PM
Re: for(size_t a=begin();a!=end();++a){} Chris \( Val \) C++ 2 07-14-2003 06:31 AM
Re: size_t ... standards Howard Hinnant C++ 5 06-30-2003 07:22 PM
Re: size_t ... standards Howard Hinnant C++ 0 06-29-2003 05:45 PM



Advertisments