size_t problems

[Ian Collins]

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
}

Why would you want a signed loop index for a zero to unsigned range?

I may sound pedantic, but keeping signed and unsigned quantities apart
avoids nasty bugs.

 

[Richard Heathfield]

Ian Collins said:

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

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?

 

[Ian Collins]

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]

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

It beats work...

 

[jacob navia]

It beats work...

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

 

[Ian Collins]

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

Bad humour day today?

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

 

[Thad Smith]

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.

 

[Ben Pfaff]

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.

 

[Richard Heathfield]

Ian Collins said:

Bad humour day today?

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

Some people's pennies are in orbit.

 

[jacob navia]

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]

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.

 

[Richard Heathfield]

Ben Pfaff said:

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.

 

[Malcolm McLean]

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

 

[Keith Thompson]

Which I said, and you snipped. Why?

Sorry, I didn't realize I was repeating some of what you said.

 

[Richard]

Ben Pfaff said:


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.

Ridiculous. Everything doesn't have the "right type" to start
with. Hence the chain reaction.

Millions of programmers the world over use int as a size store for
strings they know to be only a "few bytes" long. It might not be "right"
now, but there is a huge legacy of it.

A chain reaction of this type in a huge legacy code base could cause
all sorts of side effects. You tell the head of QA that moving from int
to size_t will "just work". Not in the real world it doesn't.

 

[CBFalconer]

.... snip ...

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

I fail to see any reason why that 'i' should not be declared as
unsigned. Well, maybe extreme laziness.

 

[CBFalconer]

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

No, that will eventually lead to more accurate code with fewer
concealed traps. This is C, not B. The fact that you ignore all
these recommendations is a strong indication that your code is not
safe to use.

 

[CBFalconer]

Ian Collins said:

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?

Now that is not fair. Yes, Jacob has peculiar (and many are
unsound) ideas, but that does not make him a troll. He seems to
have co-operated on advertising his compiler, for example, without
specifically acknowledgeing so doing.

 

[CBFalconer]

Ian Collins said:

Some people's pennies are in orbit.

That sounds like a pure Britticism. I suspect a connection with
pay-toilets of bygone days. Is a British penny still roughly one
nautical mile in diameter?

 

[CBFalconer]

.... snip ...

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!

Why? Nothing can create a problem unless you pass its value to an
int, and that value is outside the range that that int can
express. If that happens, lo, you have found a bug. Meanwhile you
have the opportunity to use shift operations on it, to overflow it
without creating unsomething situations, etc.