size_t problems

[jacob navia]

Re: size_t problems

Craig Gullixson wrote:

In article <46d87532$0$507 2$ba4acef3@news .orange.fr>,
jacob navia <jacob@jacob.re mcomp.frwrites:

>Ian Collins wrote:

>>jacob navia wrote:
>>>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.
>>>

>If aint'broken do not fix it
>>

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

>

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

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]

Re: size_t problems

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

>
"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:snulq4x9lc .ln2@news.flash-gordon.me.uk...

>Malcolm McLean wrote, On 31/08/07 16:18:

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

>>
>Ah, he sees the light.
>>

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!

>Or perhaps not. Almost 20 years after a language is standardised is a
>bit late to start trying to change it. Especially when it has proved
>extremely successful.

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

[spacecriter \(Bill C\)]

Re: size_t problems


Keith Thompson wrote:

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

>spacecriter (Bill C) wrote:

>>I assume that you don't want to redefine s as a size_t because it
>>may be used elsewhere as an int, and you would rather not track
>>down everywhere it may be used. So why not replace all the
>>strlen() calls with your own function (maybe call it i_strlen(), or
>>somesuch name) that returns an int?
>>>

>That would be a good solution!
>>
>THANKS!

>
Hmm, sounds familiar.
>

>I suppose you could write a strlen wrapper that calls the real
>strlen, checks whether the result exceeds INT_MAX (if you think that
>check is worth doing), and then returns the result as an int.
>That's assuming strlen calls are the only things triggering the
>warnings. And you'd still have to make hundreds of changes in the
>code.

>
<http://groups.google.c om/group/comp.lang.c/msg/3ef33439c43be6a c>

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.


--
Bill C.

[Ben Bacarisse]

Re: size_t problems

"Malcolm McLean" <regniztar@btin ternet.comwrite s:

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:snulq4x9lc .ln2@news.flash-gordon.me.uk...

>Malcolm McLean wrote, On 31/08/07 16:18:

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

>>
>Ah, he sees the light.
>>

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.

--
Ben.

[pete]

Re: size_t problems

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

[pete]

Re: size_t problems

Richard Tobin wrote:

>
In article <87zm07lp7l.fsf @blp.benpfaff.o rg>,
Ben Pfaff <blp@cs.stanfor d.eduwrote:
>

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

[pete]

Re: size_t problems

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.

--
pete

[Richard Heathfield]

Re: size_t problems

CBFalconer said:

jacob navia wrote:

>>

... snip ...

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

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

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

pete wrote:

Richard Tobin wrote:

>Ben Pfaff <blp@cs.stanfor d.eduwrote:
>>

>>An array of char can potentially have an index range of
>>0...SIZE_MA X. 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] = i; /* legal */

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


"Ben Bacarisse" <ben.usenet@bsb .me.ukwrote in message
news:87642vfc2s .fsf@bsb.me.uk. ..

"Malcolm McLean" <regniztar@btin ternet.comwrite s:
>

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

Two things will happen.
Probably there will be a howl of protest as desktop programs move from 32 to
64 bits, and the implications of size_t being no longer the same size as an
int (give or take a sign bit) become obvious. So something will be done, and
people will look at code saying size_t i and say "Oh, that garbage the
committee inisted on back in 2007? What obsolete code."

The other possibility is that the committee will have its way, and we've all
got to write size_t for practically every array index. This makes C a
difficult language, OK for the specialist, but not very good for beginner
use. So it is no longer a good choice for a beginning book. Either use a
different language, or use a cut down, simplified version of the existing
language, with a note to say what you've done.

Either way, it is a bad idea to always follow the latest fashion in
programming. That way you've got to keep on rewriting things.


--
Free games and programming goodies.

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

[Richard Heathfield]

Re: size_t problems

Malcolm McLean said:

<snip>

Probably there will be a howl of protest as desktop programs move from
32 to 64 bits,

Why? Surely everyone has learned their lesson from the early 1990s -
"don't rely on exact-size types, or your code will break one day" -
haven't they?

and the implications of size_t being no longer the same
size as an int (give or take a sign bit) become obvious.

It has never been the case that size_t is the same size as an int,
except by coincidence. ints are sizeof(int) bytes big, whereas size_ts
are sizeof(size_t) bytes big. If these values are the same, that's an
interesting coincidence, but nothing more.

So something
will be done, and people will look at code saying size_t i and say
"Oh, that garbage the committee inisted on back in 2007? What obsolete
code."

(a) far from being garbage, size_t is a useful type;
(b) the committee codified size_t is 1989, not 2007;
(c) far from being obsolete, code that uses proper types in the proper
way is more likely to survive and flourish than code that does not.

<snip>

Either way, it is a bad idea to always follow the latest fashion in
programming.

Such as, say, 64-bit ints.

That way you've got to keep on rewriting things.

Precisely. Whereas, if you use the proper types in the right way, you
are less likely to have to do that.

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

[Keith Thompson]

Re: size_t problems

CBFalconer <cbfalconer@yah oo.comwrites:

pete wrote:

>Richard Tobin wrote:

>>Ben Pfaff <blp@cs.stanfor d.eduwrote:
>>>
>>>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] = i; /* legal */

No, there's no such thing as an array with indices -3 through 6 -- and
atwo is a pointer, not an array. But a good case could be made that
atwo points to the first element of an array of length 7 (that happens
to overlap the last 7 elements of aone). I'm not sure just how good a
case can be made; it depends on the exact wording of the standard
(which I don't have handy at the moment).

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

[Ian Collins]

Re: size_t problems

Malcolm McLean wrote:

"Ben Bacarisse" <ben.usenet@bsb .me.ukwrote:

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

Two things will happen.
Probably there will be a howl of protest as desktop programs move from
32 to 64 bits, and the implications of size_t being no longer the same
size as an int (give or take a sign bit) become obvious. So something
will be done, and people will look at code saying size_t i and say "Oh,
that garbage the committee inisted on back in 2007? What obsolete code."
>

Those of us with decent desktops have been in the 64 bit world for well
over a decade and I haven't heard any howls yet.

The other possibility is that the committee will have its way, and we've
all got to write size_t for practically every array index.

They've had their way since 1989, where have you been? 64 bit desktops
started to appear shortly after.

This makes C
a difficult language, OK for the specialist, but not very good for
beginner use. So it is no longer a good choice for a beginning book.

Are you really saying too hard for windows programmers?

>
Either way, it is a bad idea to always follow the latest fashion in
programming. That way you've got to keep on rewriting things.
>

You must be behind the times Malcolm, there have been plenty of fashions
that have been and gone in the past 18 years.


--
Ian Collins.

[pete]

Re: size_t problems

CBFalconer wrote:

>
pete wrote:

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] = i; /* legal */

(&aone[3]) is the address of an object of type int.
Your disproof is irrelevant to my statement.

--
pete

[Richard Tobin]

Re: size_t problems

In article <lnd4x2kdbk.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.orgwrote:

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

>No, there's no such thing as an array with indices -3 through 6 -- and
>atwo is a pointer, not an array.

That's why I said "for a sufficiently restricted interpretation of
array index". How the standard defines array is unimportant; the
point is that in indexing, both sizes (which "should" be unsigned
size_ts) and offsets (both negative and positive) are used and
combined and compared. So I find the fact that sizes are inherently
positive unconvincing as an argument for their being unsigned.

The *real* reason for their being unsigned is that the good sizes for
signed ints have in the past been inadequate for addressing all
objects. At the risk of sounding like Mr Gates, I suggest that 63
bits will be quite adequate for object sizes throughout the future
life of C.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.