size_t problems

[christian.bau]

jacob navia wrote:
Richard Tobin wrote:




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.

for (i = strlen (s) - 1; i >= 0; --i) ...

loops through all characters in a string in reverse order, as long as
the length of s is not excessive, if i is a signed 32 bit or longer
integer. Now write that with an unsigned type without any convoluted
code.

 

[Malcolm McLean]

for (i = strlen (s) - 1; i >= 0; --i) ...

loops through all characters in a string in reverse order, as long as
the length of s is not excessive, if i is a signed 32 bit or longer
integer. Now write that with an unsigned type without any convoluted
code.

size_t i = strlen(s);
while(i--)
{
/* loop body */
}

 

[CBFalconer]

.... snip ...


for (i = strlen (s) - 1; i >= 0; --i) ...

loops through all characters in a string in reverse order, as long
as the length of s is not excessive, if i is a signed 32 bit or
longer integer. Now write that with an unsigned type without any
convoluted code.

for (i = strlen(s), j = i-1; i; j = i--) {
.... s[j] ....
}

 

[pete]

"christian.bau" <[email protected]>
wrote in message

size_t i = strlen(s);
while(i--)
{
/* loop body */
}

Well done!

 

[Richard Heathfield]

CBFalconer said:

That sounds like a pure Britticism.

Well, if you'll pardon the expression, I coined it myself especially for
this thread. And yes, I'm British. So I suppose you're right.

I suspect a connection with pay-toilets of bygone days.

No, none.

Is a British penny still roughly one nautical mile in diameter?

No, and it never has been.

 

[Richard Heathfield]

CBFalconer said:

Yes, Jacob has peculiar (and many are
unsound) ideas, but that does not make him a troll.

The only alternative I can envisage is that he is utterly brainless. Is
that the theory you prefer?

Look at the facts. We've spent years trying to educate him in the
basics, and failed. If we were unfortunate enough to hire someone like
that, we'd have given him up as a bad job years ago and shuffled him
off into marketing (if we lacked the gumption to sack him outright). We
certainly wouldn't let him anywhere near our compiler-writing division.

 

[Peter J. Holzer]

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.

No. Comparison with signed int also creates problems.

int i = -5;
unsigned u = 5;
if (i > u) printf("Gotcha!\n");

A C programmer should be aware of this when writing code. But if you
change types in existing code, something like that is easy to miss.
Of course Jacob already wrote that his compiler warns about this
problem, so he'll just have to change the type of the next variable or
add a cast.

hp

 

[Peter J. Holzer]

Clearly with strlen() the chance of it being an error is negligible.
And I think this is true other size_t->int assignments. For example,
int s = sizeof(whatever) is almost never a problem.

Since sizeof(whatever) can be evaluated at compile time (except
when a variable length array is involved), the compiler can even know
exactly when it is a problem.

hp

 

[Peter J. Holzer]

I work in that field.
Whilst generally you'd want a "rope" type-structure to handle such a long
sequence, there might well be reasons for storing the whole genome as a flat
string. Certainly if I had a 64-bit machine with enough memory installed, I
would expect to have the option, and I'd expect to be able to write the
program in regular C.

Nothing Richard wrote would prevent you from writing your programs in
regular C. All he suggested was that you should be able to turn off the
warning "64 bit value assigned to 32 bit variable" independently from
other "wide value assigned to narrow variable" warnings.

hp

 

[Philip Potter]

That sounds like a pure Britticism.

I suspect after a while you'll understand what RH was referring to, and the
low-value copper coinage will descend.

Phil

 

[Richard Heathfield]

Peter J. Holzer said:

Comparison with signed int also creates problems.

int i = -5;
unsigned u = 5;
if (i > u) printf("Gotcha!\n");

Indeed. Nevertheless, we must ask why values of two different types are
being compared in this way. Which is greater, half a pound of cheese or
a dozen eggs?

 

[CBFalconer]

CBFalconer said:
.... snip ...


No, and it never has been.

It was when I was last there mumble years ago. Roughly 1 inch
diameter, thick, and two or three in your pocket would tear holes
in the presence of gravity. Much like smoke tests of equipment.

 

[CBFalconer]

CBFalconer said:



The only alternative I can envisage is that he is utterly brainless.
Is that the theory you prefer?

I'm just dealing with facts. Let him pick the theory under which
he exists around here. Words and actions count.

Look at the facts. We've spent years trying to educate him in the
basics, and failed. If we were unfortunate enough to hire someone
like that, we'd have given him up as a bad job years ago and
shuffled him off into marketing (if we lacked the gumption to sack
him outright). We certainly wouldn't let him anywhere near our
compiler-writing division.

Without supervision, yes. This leaves him apparently peculiar.
Maybe he is a big act.

 

[CBFalconer]

No. Comparison with signed int also creates problems.

But you don't do that, and if you do the compiler should warn.
Things of different types shouldn't be compared, and is unnecessary
(unless you mis-type variables).

 

[Richard Tobin]

int s = strlen(str) is NOT broken.

[/QUOTE]

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

There are lots of reasons to assign an unsigned value to an int. Most
notably, so that you can do integer arithmetic on it. Do you really
want all array subscript variables to be size_t? If so, you'll have
to consider casting them if, say, you want to subtract one from
another.

-- Richard

 

[Ben Bacarisse]

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

One last time, maybe? size_t *fixes* a problem. The solution is not
without pain in legacy code, but size_t is _over 17 years old_ now.
You create a problem when you write a book, ostensibly for beginners,
that perpetuates the problems of legacy code! Your excellent post in
an other thread, shows that many of the "problems" with unsigned sizes
are figments (counting down an unsigned value).

You have no solution to offer anyone. 64 bit ints won't wash (for
Jabob Navia's problem) until MS buys the T-shirt, and not doing
anything would have caused just as many, of not more, problems in the
last 18 years. Taking pot-shots and an imperfect solution is one
thing, but you have to come up with something constructive to be taken
seriously.

 

[Ben Pfaff]

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

My code does in fact end up using size_t quite often. If I were
perfectly consistent, it would probably use size_t even more
often. Why is that a problem?

 

[Bart]

Peter J. Holzer said:




Indeed. Nevertheless, we must ask why values of two different types are
being compared in this way. Which is greater, half a pound of cheese or
a dozen eggs?

Not quite the same. If I have a container that can hold 0 to 12 eggs
and another that can hold (use some imagination) -6 to 6 eggs, it's
easy enough to compare say 4 in one with +3 in the other (the first
will make a bigger omelette).

I don't see a problem in comparing 0..12 with -6..6. Of course to
implement such a thing in a machine it may be necessary to do some
conversion first (such as both move sets of eggs to boxes that can
hold -6 to 12).

Bart

 

[Ed Jensen]

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.

Just out of curiosity, what was the rationale behind having strlen()
return size_t instead of "int" or "unsigned int" in the first place?

 

[Kenny McCormack]

You have no solution to offer anyone. 64 bit ints won't wash (for
Jabob Navia's problem) until MS buys the T-shirt, and not doing
anything would have caused just as many, of not more, problems in the
last 18 years. Taking pot-shots and an imperfect solution is one
thing, but you have to come up with something constructive to be taken
seriously.

Like you??? (And Default Loser - both of you just post carp)