size_t problems

C

christian.bau

jacob said:
Ian said:
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.
 
M

Malcolm McLean

christian.bau said:
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 */
}
 
C

CBFalconer

christian.bau said:
.... 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] ....
}
 
R

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

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

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
 
P

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
 
P

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
 
P

Philip Potter

CBFalconer said:
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
 
R

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

CBFalconer

Richard said:
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.
 
C

CBFalconer

Richard said:
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.
 
C

CBFalconer

Peter J. Holzer said:
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).
 
R

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
 
B

Ben Bacarisse

Malcolm McLean said:
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.
 
B

Ben Pfaff

Malcolm McLean said:
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?
 
B

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
 
E

Ed Jensen

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

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

Kenny McCormack

Ben Bacarisse said:
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)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

size_t, ssize_t and ptrdiff_t 56
The problem with size_t 45
size_t 18
size_t in inttypes.h 4
mixed declarations and code (and size_t)? 7
64 bit porting - size_t vs unsigned int 7
size_t in C++ 0
size_t - why? 18

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top