size_t problems

[Keith Thompson]

Re: size_t problems

CBFalconer <cbfalconer@yah oo.comwrites:

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_Keit h) kst-u@mib.org <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"

[jacob navia]

Re: size_t problems

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!

[Richard Heathfield]

Re: size_t problems

Ian Collins said:

jacob navia wrote:

<snip>

>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?

Well, obviously it doesn't make any sense at all, and assigning strlen's
result to an int is clearly wrong; strlen yields size_t, not int.

On the other hand, does it really make sense to play with trolls?

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

Re: size_t problems

jacob navia wrote:

>
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!

Name one.

--
Ian Collins.

[Ian Collins]

Re: size_t problems

Richard Heathfield wrote:

>
On the other hand, does it really make sense to play with trolls?
>

It beats work...

--
Ian Collins.

[jacob navia]

Re: size_t problems

Ian Collins wrote:

Richard Heathfield wrote:

>On the other hand, does it really make sense to play with trolls?
>>

It beats work...
>

OK. You win. Will not answer any posts from you.

[Ian Collins]

Re: size_t problems

jacob navia wrote:

Ian Collins wrote:

>Richard Heathfield wrote:

>>On the other hand, does it really make sense to play with trolls?
>>>

>It beats work...
>>

>
OK. You win. Will not answer any posts from you.

Bad humour day today?

You normally stop once you realise I'm correct...

--
Ian Collins.

[Thad Smith]

Re: size_t problems

jacob navia wrote:

int s;
>
// ...
s = strlen(str) ;
>
Since strlen returns a size_t, we have a 64 bit result being
assigned to a 32 bit int.

....

Since I warn each time a narrowing conversion is done (since
that could loose data) I end up with hundreds of warnings each time
a construct like int a = strlen(...) appears. This clutters
everything, and important warnings go lost.

I suggest a warning switch for the 64 bit to 32 bit conversion separate
from warnings for other narrowing conversions.

--
Thad

[Ben Pfaff]

Re: size_t problems

jacob navia <jacob@jacob.re mcomp.frwrites:

Ian Collins wrote:

>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...

Only if 'i' is declared as type 'int'. If you declare it to have
type 'size_t', you will not have a problem.
--
char a[]="\n .CJacehknorstu" ;int putchar(int);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,0x11f6} ,*p
=b,i=24;for(;p+ =!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Richard Heathfield]

Re: size_t problems

Ian Collins said:

jacob navia wrote:

>Ian Collins wrote:

>>Richard Heathfield wrote:
>>>On the other hand, does it really make sense to play with trolls?
>>>>
>>It beats work...
>>>

>>
>OK. You win. Will not answer any posts from you.

>
Bad humour day today?
>
You normally stop once you realise I'm correct...

Some people's pennies are in orbit.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Re: size_t problems

Ben Pfaff wrote:

jacob navia <jacob@jacob.re mcomp.frwrites:
>

>Ian Collins wrote:

>>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...

>
Only if 'i' is declared as type 'int'. If you declare it to have
type 'size_t', you will not have a problem.

Of course, but that will lead to MORE changes in a chain reaction
that looks quite dangerous...

[Ben Pfaff]

Re: size_t problems

jacob navia <jacob@jacob.re mcomp.frwrites:

Ben Pfaff wrote:

>jacob navia <jacob@jacob.re mcomp.frwrites:

>>Ian Collins wrote:
>>>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...

>>
>Only if 'i' is declared as type 'int'. If you declare it to have
>type 'size_t', you will not have a problem.

>
Of course, but that will lead to MORE changes in a chain reaction
that looks quite dangerous...

It is of course possible to run into problems. If you have code
that you know to work in a given environment, then you may not
want to fix it, because it may break that code in that same
environment if you fail to understand the consequences of the
series of changes. But in this case you're talking about moving
the code to a new environment anyhow (32- to 64-bit), in which
case the code has to be tested anew. The choice is then between
maintaining the old version and the new version separately, as
different pieces of code, or making sure that the fixed version
works in both environments. Most of the time, I'd choose the
latter.
--
char a[]="\n .CJacehknorstu" ;int putchar(int);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,0x11f6} ,*p
=b,i=24;for(;p+ =!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Richard Heathfield]

Re: size_t problems

Ben Pfaff said:

jacob navia <jacob@jacob.re mcomp.frwrites:
>

>Ben Pfaff wrote:

>>jacob navia <jacob@jacob.re mcomp.frwrites:

<snip>

>>>The i<len comparison would provoke a warning if len is unsigned...
>>>
>>Only if 'i' is declared as type 'int'. If you declare it to have
>>type 'size_t', you will not have a problem.

>>
>Of course, but that will lead to MORE changes in a chain reaction
>that looks quite dangerous...

>
It is of course possible to run into problems.

It is also possible to steer clear of problems. The "chain reaction"
simply doesn't happen if everything has the right type to start off
with. And if it doesn't, the chain reaction is a good thing, not a bad
thing, because it reveals type misconceptions in the code.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Re: size_t problems

Keith Thompson wrote:

CBFalconer <cbfalconer@yah oo.comwrites:

>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

[Malcolm McLean]

Re: size_t problems


"jacob navia" <jacob@jacob.re mcomp.frwrote in message
news:46d6676c$0 $27368$ba4acef3 @news.orange.fr ...

Ben Pfaff wrote:
>

>Only if 'i' is declared as type 'int'. If you declare it to have
>type 'size_t', you will not have a problem.

>
Of course, but that will lead to MORE changes in a chain reaction
that looks quite dangerous...
>

Now you are realising the problem.
In fact if you use size_t safely and consistently, virtually all ints need
to be size_t's. The committee have managed to produce a very far-reaching
change to the C language, simply though fixing up a slight problem in the
interface to malloc().

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm