size_t problems

[Ian Collins]

Ian Collins:



Depends entirely on the nature of the code. I've written portable code
before that is littered with casts for very good reasons.

I'd wager it could be written without most, or even all of them.

In the little snippet I wrote just above, I'd only write a comment
with it if my target audience only started programming yesterday at 3
O'Clock.

That's because it can be written without the cast.

IMO, any decent compiler should issue truncation warnings.

Do you know of a "decent compiler" that does?

 

[Ian Collins]

Yes qsort() takes two size_t's as well. So we are OK. The system does
work, but only so long as we are absolutely consistent in using size_t
everywhere.

Isn't consistency one of the foundations of our art?

 

[Ian Collins]

int Strlen_i(char *s)
{
char *start=s;
while (*s)
s++;
return s-start;
}
#define strlen Strlen_i;

You really should bite the bullet and fix the code.

The transition form 32 to 64 bits isn't without pain, whether the return
is worth the pain is a choice of the developer.

There a some good papers on transitioning from 32 to 64 bit environments
to be found on the web. I'm sure the number (if not the quality) will
increase as the windows world catches up with the rest of us.

 

[jacob navia]

You really should bite the bullet and fix the code.

If aint'broken do not fix it

There is no simple solution. It means go over the
code and put casts everywhere, fix the new bugs
as you dscover them, etc.

Don't feel like it. There are more interesting things to do.

The transition form 32 to 64 bits isn't without pain, whether the return
is worth the pain is a choice of the developer.

Well, my compiler system is up and running in 64 bits...
I have to fix the debugger though, and many other stuff...

There a some good papers on transitioning from 32 to 64 bit environments
to be found on the web. I'm sure the number (if not the quality) will
increase as the windows world catches up with the rest of us.

Yes, I know. I have read most of them.

 

[Malcolm McLean]

Isn't consistency one of the foundations of our art?

Yes. But psychological factors are also important. If an index variable is
called "size" then of course the compiler will happily chug through and
index the array by variable "size". However to anyone reading the program it
is intensely irritating.
The same goes for variables which don't hold amounts of memory being called
by a name that suggests that this is their function.

If you allow a meaningful, but wrong type, called "int", and a correct but
misleadingly named type, called "size_t", how many programmers are going to
be consistent with their use of size_t. Especially in the case of a routine
like qsort() where it is not immediately apparent that the count, as opposed
to element size, has to be a size_t. However if a function called mean()
also takes a size_t, and calls qsort(), then this really is necessary.
Otherwise mean() has to include silly checks against INT_MAX, and then
document its oddball restrictions. That's what will happen in reality, with
user-supplied sort routines.

 

[Keith Thompson]

Yes. But psychological factors are also important. If an index
variable is called "size" then of course the compiler will happily
chug through and index the array by variable "size". However to anyone
reading the program it is intensely irritating.
The same goes for variables which don't hold amounts of memory being
called by a name that suggests that this is their function.

[...]

Get over it. Learn what "size_t" means; there's more to it than how
it's spelled.

 

[Craig Gullixson]

If aint'broken do not fix it

But it *is* broken as far as the C standard is concerned.

There is no simple solution. It means go over the
code and put casts everywhere, fix the new bugs
as you dscover them, etc.

Don't feel like it. There are more interesting things to do.

If one believes in the engineering aspect of software development,
then maintenance is part of the deal. As pointed out elsewhere in
this thread, size_t has been around for 18 years so having to deal
with it should not exactly be a surprise.

That being said, you are free to either deal with updating your code
or to ignore the compiler warnings. It all depends on how much you
and those others who use the code care about it working correctly and
how difficult it is to port to other compilers, platforms, operating
systems, etc., when needed.

As an example of consequences of not keeping code up to date, I've
spent something in excess of a week getting a network communications
package for a little I/O box embeded in one of our systems to compile
and work correctly after an OS/compiler upgrade of the system needing
to use the I/O box. It turns out that the latest version of the
software package supplied by the vender is *full* of pre C89 crud.
I now have the system working again to the point that it is useful,
however the porting hassles serve as a disincentive for purchasing any
more of the company's products.

Well, my compiler system is up and running in 64 bits...
I have to fix the debugger though, and many other stuff...


Yes, I know. I have read most of them.

--
________________________________________________________________________
Craig A. Gullixson
Instrument Engineer INTERNET: (e-mail address removed)
National Solar Observatory/Sac. Peak PHONE: (505) 434-7065
Sunspot, NM 88349 USA FAX: (505) 434-7029

 

[Ian Collins]

Ian Collins wrote:
If aint'broken do not fix it

But is is. Quarts don't fit into pint pots.

There is no simple solution. It means go over the
code and put casts everywhere, fix the new bugs
as you dscover them, etc.

Casts that hide turds are a good reason to have strict (process) rules
regarding their use. I've even worked at a shop where casts has to pass
a design review, which I thought was overkill at the time. I now know
better.

Don't feel like it. There are more interesting things to do.

I don't feel like paying my bills, there are more interesting things to
do. Unfortunately they will get me in the end.

Yes, I know. I have read most of them.

But did you learn from them?

 

[Keith Thompson]

But is is. Quarts don't fit into pint pots.

The counterargument is that the contents of a quart pot can be poured
into a pint pot if the quart pot is less than half full. That appears
to be the case here (the code invokes strlen on strings that,
apparently, are known with some confidence to be shorter than INT_MAX
bytes).

Nevertheless, strlen() returns size_t for a good reason, and the
result should be stored in a size_t object unless there's a good
reason not to do so. (One possible reason is that fixing legacy code
would be more effort than it's worth.)

 

[Ian Collins]

Nevertheless, strlen() returns size_t for a good reason, and the
result should be stored in a size_t object unless there's a good
reason not to do so. (One possible reason is that fixing legacy code
would be more effort than it's worth.)

Unfortunately the fixes take on a whole new significance when porting
from 32 to 64 bit.

 

[jacob navia]

But it *is* broken as far as the C standard is concerned.

Look, it is not the C standard that runs my code.

It is a mindless processor, churning instruction after instruction, no
mind no standards, no nothing.

I have an aesthetic view of code. What is important in it, from my
viewpoint, is clarity of design and above all, that
IT WORKS.

Code can be written up to the best standards, but if doesn't work or if
it doesn't perform very well I do not care. It is ugly.

The code I am porting is the code of the IDE of lcc-win, and the code of
the debugger. I started writing it around 1992.

The IDE was one of the few pieces of code I salvaged from my failed
lisp interpreter project, that was a technical success but a commercial
failure.

It has been ported to windows 16 bits (from 32 bit DOS emulator with
Delorie), then ported to windows 32 bits in 1996 (windows 95), then
ported to linux 32 bits , under GTK, and then to windows 64 bits.

Believe me, I know what porting means, what is important in code
what is not.

If one believes in the engineering aspect of software development,
then maintenance is part of the deal. As pointed out elsewhere in
this thread, size_t has been around for 18 years so having to deal
with it should not exactly be a surprise.

Yeah. I have to cope with the possibility of strings larger than 2GB.
Gosh!

That being said, you are free to either deal with updating your code
or to ignore the compiler warnings. It all depends on how much you
and those others who use the code care about it working correctly and
how difficult it is to port to other compilers, platforms, operating
systems, etc., when needed.

I think that the fix proposed will fit the bill.

As an example of consequences of not keeping code up to date, I've
spent something in excess of a week getting a network communications
package for a little I/O box embeded in one of our systems to compile
and work correctly after an OS/compiler upgrade of the system needing
to use the I/O box. It turns out that the latest version of the
software package supplied by the vender is *full* of pre C89 crud.

You will agree with me that THAT is much serious than a few compiler
warnings because of size_t I suppose...

I adopted immediately C89 when it come out, because of the prototypes.
It was an INCREDIBLE relaxing thing that I did NOT have to worry
anymore if I always passed the right number of parameters to my
functions. The compiler would yell at me. What a fantastic feeling.
I still remember it!

I now have the system working again to the point that it is useful,
however the porting hassles serve as a disincentive for purchasing any
more of the company's products.

Sorry but did you contact the vendor? If they still exists and
sell that package they have surely upgraded it...

 

[Flash Gordon]

Malcolm McLean wrote, On 31/08/07 19:27:

That's why Basic Algorithms is absolutely consistent in using int.

Therefore being inconsistent with the standard for the language your
claim to want to use.

Otherwise I would either have to translate everything to size_t, or you
would rapidly risk a mess.

Shock horror, if you do only part of your code correctly you get a mess!
The obvious solution is to write all of it correctly!

You have not addressed the points above. A reasonable assumption is that
this is because you realise you don't have a good argument against them.

Effectively we are in a hiatus between standards. It looks like C99 will
never be widely implemented. So now is the time to get those nasty
size_t's out of our code.

Not everyone thinks they are nasty. In any case, comp.std.c is the place
to propose changes to the standard.

 

[Ben Bacarisse]

That's why Basic Algorithms is absolutely consistent in using
int. Otherwise I would either have to translate everything to size_t,
or you would rapidly risk a mess.

I can't understand why, since you acknowledge that part of the problem
is old code that uses int[1], you choose to perpetuate the problem in a
new book.

If you don't like the under score or the name for pedagogic reasons
just use a typedef in all the code (yes, someone else suggested this
already, my apologies for not looking up a giving credit -- it is
late). How about

typedef size_t cardinality;

? That suggests counting, indexing and size all in one.

[1] Elsewhere. It is not in the quoted text.

 

[pete]

Ben Pfaff wrote:

An array of char can potentially have an index range of
0...SIZE_MAX.

Almost.
For

char array[SIZE_MAX];

the lvalue of the last element is (array[SIZE_MAX - 1]).

 

[pete]

An array of char can potentially have an index range of
0...SIZE_MAX. An array of any larger object type has a more
limited index range. Therefore, size_t is always a suitable type
for representing an array index.

For a sufficiently restricted interpretation of array index. p[-3]
can be perfectly legal.

If (&p) is the address of an object of an array type,
then p[-3] isn't defined.

 

[pete]

jacob navia wrote:

If aint'broken do not fix it

There is no simple solution.

There can't be any solution of any kind, if it aint'broken.

 

[spacecriter \(Bill C\)]

Hmm, sounds familiar.


<http://groups.google.com/group/comp.lang.c/msg/3ef33439c43be6ac>

Precicely what I had in mind with the suggestion. I guess I missed your
previous post.

Presumably, his code worked in 32-bit mode, so his new function should
emulate behavior of the 32-bit version of strlen. That *should* keep it
from beaking anything downstream. That should include casting the unsigned
result into an int.

 

[Richard Heathfield]

CBFalconer said:

At which point your code has undefined behaviour.

No, at which point his code won't even compile.

Please read the standard some day.

I think he should start with something a little easier to understand.

 

[Charles Richmond]

A nautical mile is a minute of arc of the Earth's great circle. About
6,080 feet or 72,960 inches. That would be a 'Pretty' penny indeed.

It's a hyperbole, guys!!! A hyperbole!!! Look it up...

 

[CBFalconer]

An array of char can potentially have an index range of
0...SIZE_MAX. An array of any larger object type has a more
limited index range. Therefore, size_t is always a suitable
type for representing an array index.

For a sufficiently restricted interpretation of array index.
p[-3] can be perfectly legal.

If (&p) is the address of an object of an array type,
then p[-3] isn't defined.

Disproof:

int aone[10];
int *const atwo = &aone[3];
/* atwo is now effectively an array of indices -3 thru 6 */
...
int i;
for (i = -3; i < 7; i++) atwo = i; /* legal */