HeathField Strange Ideas!

[Malcolm McLean]

Can you give an example of the problem? I'm confused as to what your issue
is.

size_t is not just used for sizes of memory, it is also used to count
arrays. If it was used perfectly consistently then int would fade away,
because only a few integers are used as natural numbers, the vast majority
count or index things, or are used in intermediate calculations to derive
indexes. (This is true even for char, if you think about it, eventually it
is used to index into a character table for display to a human).
However size_t will not be used consistently for everything that counts or
indexes item in memory. People will still not infrequently use int. So the
result is a mishmash of integer types. So you end up writing little routines
to convert arrays of int to size_t s and back again, even though they are
all the same underlying bit representation, all because Fred wants a list of
ints and Jim a list of size_ts.

 

[Ian Collins]

The problem is that pedantry can blind you to real issues.

That's why I said "in my team", team is important.

 

[pete]

The problem is that pedantry can blind you to real issues.

I don't think Richard Heathfield has really
taken on board my point about
the language-destroying potential of size_t and allied types.

Do you think that anybody else has?

 

[Spiros Bousbouras]

What on earth are you speaking about? You can index an array with
whatever integral value you like most.

If this needs to be discussed at all it should be in its
own thread rather than in one which is blatantly a trolling
attempt.

Oh , and everyone

***************************************
*** Please do not feed the trolls ***
***************************************

 

[Army1987]

size_t is not just used for sizes of memory, it is also used to count
arrays. If it was used perfectly consistently then int would fade away,
because only a few integers are used as natural numbers, the vast majority
count or index things, or are used in intermediate calculations to derive
indexes. (This is true even for char, if you think about it, eventually it
is used to index into a character table for display to a human).

Yeah.
EOF is always used to index arrays. EXIT_SUCCESS and EXIT_FAILURE
are always used to index arrays. Boolean flags are used to index
arrays. Enumeration constants too.

However size_t will not be used consistently for everything that counts or
indexes item in memory. People will still not infrequently use int. So the
result is a mishmash of integer types. So you end up writing little routines
to convert arrays of int to size_t s and back again, even though they are
all the same underlying bit representation, all because Fred wants a list of
ints and Jim a list of size_ts.

Huh?

 

[Malcolm McLean]

Yeah.
EOF is always used to index arrays. EXIT_SUCCESS and EXIT_FAILURE
are always used to index arrays. Boolean flags are used to index
arrays. Enumeration constants too.

The vast majority ...
What part of that can't you read? Of course you can come up with a few
examples of integers that are not so used.

 

[Malcolm McLean]

Do you think that anybody else has?

Ben Bacarisse has I think got the idea. That's not to say he agrees with me,
but he sees the implications of allowing size_t into code, and understands
why I resist.
People eventually convert, but it is a long process. Stage one is breaking
down their social behaviour, which blinds them to the intellectual merits of
the case.

 

[Ben Bacarisse]

Ben Bacarisse has I think got the idea. That's not to say he agrees
with me, but he sees the implications of allowing size_t into code,
and understands why I resist.

What on earth gave you that idea? I must work harder at my text. To
be clear: I do not think that size_t "poisons programs" or is "destroying
C"[1]. It is the correct type to use for object sizes and you can't
avoid using it if you use C correctly.[2]

Using int for an array index does not suddenly make a program wrong,
just as using size_t for them all does not make it magically correct.
If you choose to use an int for an index, you are saying that you are
happy with the consequences of doing so -- often there are none
(e.g. argc is an int and this is not a problem).

Finally, I think it is irresponsible to omit its correct use from a
book aimed at beginners (even though the book does not aim to teach
C).

People eventually convert,

The terminology is interesting. Does it explain why you refuse to
demonstrate what the problem actually is? The only one that I have
seen clearly expressed is that you don't like the _ (aesthetically).

[1] How long will size_t and C need to co-exist for you to give up the
idea that C is being destroyed by it? Serious question, because I
think only time will convince you.

[2] Because sizeof returns it and many library functions require it.
Even if you write 'int len = sizeof x;' you are using size_t -- in a
way that introduces a possible portability issue depending on what
size x may be.

 

[Malcolm McLean]

"Malcolm McLean" <[email protected]> writes:

Using int for an array index does not suddenly make a program wrong,
just as using size_t for them all does not make it magically correct.
If you choose to use an int for an index, you are saying that you are
happy with the consequences of doing so -- often there are none
(e.g. argc is an int and this is not a problem).

[2] Because sizeof returns it and many library functions require it.
Even if you write 'int len = sizeof x;' you are using size_t -- in a
way that introduces a possible portability issue depending on what
size x may be.

You've basically got it.
That's the problem with size_t.
If we were forced to use size_t all the time the objection would be merely
to its ugly spelling and unsignedness. As it is it a poison that propagates
through code, destroying the compatibility of functions with each other,
because most people will still e int where strictly it should be a size_t.
Make int 64 bits and all the problems disappear.

 

[Charlton Wilbur]

ES> You may not remember the Bad Old Days when everyone with what
ES> he thought was a Good Idea promptly enshrined it in his
ES> compiler and/or his library;

You mean this has stopped happening?

I guess the recent thread in which a poster discovered that the
operator overloading and primitive String type offered by lcc-win32
were not paart of standard C must have been an odd nightmare....

Charlton

 

[Ben Bacarisse]

"Malcolm McLean" <[email protected]> writes:

Using int for an array index does not suddenly make a program wrong,
just as using size_t for them all does not make it magically correct.
If you choose to use an int for an index, you are saying that you are
happy with the consequences of doing so -- often there are none
(e.g. argc is an int and this is not a problem).

[2] Because sizeof returns it and many library functions require it.
Even if you write 'int len = sizeof x;' you are using size_t -- in a
way that introduces a possible portability issue depending on what
size x may be.

You've basically got it.
That's the problem with size_t.
If we were forced to use size_t all the time the objection would be
merely to its ugly spelling and unsignedness. As it is it a poison
that propagates through code, destroying the compatibility of
functions with each other, because most people will still e int where
strictly it should be a size_t.
Make int 64 bits and all the problems disappear.

I can only assume you are being funny. I don't think I have the skill
to communicate effectively with you. Would you, at least, please
refrain from paraphrasing my opinions or suggesting that I agree with
your daft views on size_t? Thank you.

 

[Malcolm McLean]

"Malcolm McLean" <[email protected]> writes:

Using int for an array index does not suddenly make a program wrong,
just as using size_t for them all does not make it magically correct.
If you choose to use an int for an index, you are saying that you are
happy with the consequences of doing so -- often there are none
(e.g. argc is an int and this is not a problem).

[2] Because sizeof returns it and many library functions require it.
Even if you write 'int len = sizeof x;' you are using size_t -- in a
way that introduces a possible portability issue depending on what
size x may be.

You've basically got it.
That's the problem with size_t.
If we were forced to use size_t all the time the objection would be
merely to its ugly spelling and unsignedness. As it is it a poison
that propagates through code, destroying the compatibility of
functions with each other, because most people will still e int where
strictly it should be a size_t.
Make int 64 bits and all the problems disappear.

I can only assume you are being funny. I don't think I have the skill
to communicate effectively with you. Would you, at least, please
refrain from paraphrasing my opinions or suggesting that I agree with
your daft views on size_t? Thank you.

I specifically said you didn't agree with me. At least you disagree, which
is an advance.

 

[Richard]

Using int for an array index does not suddenly make a program wrong,
just as using size_t for them all does not make it magically correct.
If you choose to use an int for an index, you are saying that you are
happy with the consequences of doing so -- often there are none
(e.g. argc is an int and this is not a problem).

[2] Because sizeof returns it and many library functions require it.
Even if you write 'int len = sizeof x;' you are using size_t -- in a
way that introduces a possible portability issue depending on what
size x may be.

You've basically got it.
That's the problem with size_t.
If we were forced to use size_t all the time the objection would be
merely to its ugly spelling and unsignedness. As it is it a poison
that propagates through code, destroying the compatibility of
functions with each other, because most people will still e int where
strictly it should be a size_t.
Make int 64 bits and all the problems disappear.

I can only assume you are being funny. I don't think I have the skill
to communicate effectively with you. Would you, at least, please
refrain from paraphrasing my opinions or suggesting that I agree with
your daft views on size_t? Thank you.

I specifically said you didn't agree with me. At least you disagree,
which is an advance.

You did and he does? Sorry Malcolm, but much as I laugh at the
nitpicking and downright hostilities from some of the groups more self
satisfied, smug members, I don't think you are representing Ben's
beliefs at all here. You make it sound as if you have convinced him on
your rather unique view of how and when size_t is used.

FWIW, there are billions of lines of legacy code out there dealing with
relatively small (known before hand) strings etc which quite happily use
"int" and will, obviously, continue to do so.

 

[Malcolm McLean]

You did and he does? Sorry Malcolm, but much as I laugh at the
nitpicking and downright hostilities from some of the groups more self
satisfied, smug members, I don't think you are representing Ben's
beliefs at all here. You make it sound as if you have convinced him on
your rather unique view of how and when size_t is used.

I quoted the points he made and showed how they support my position. He of
course draws a different conclusion, but at least the basis is there. To
disagree is quite something.

FWIW, there are billions of lines of legacy code out there dealing with
relatively small (known before hand) strings etc which quite happily use
"int" and will, obviously, continue to do so.

Sure, which is half of the problem.

 

[Army1987]

The vast majority ...
What part of that can't you read? Of course you can come up with a few
examples of integers that are not so used.

The vast majority means "much more than 50%". I don't think that
many integers are used as indexes. I was only showing uses which,
IMO, cover almost or more than 50% of integers used.
(Of course, if you say that the integers in
while ((ch = getchar()) != EOF) putchar(ch);
are used to index a character table, you will never see my point.
Anyway, if nobody ever thought of having getchar() return a size_t
there are good reasons, don't you think so?)

 

[Eric Sosman]

ES> You may not remember the Bad Old Days when everyone with what
ES> he thought was a Good Idea promptly enshrined it in his
ES> compiler and/or his library;

You mean this has stopped happening?

I guess the recent thread in which a poster discovered that the
operator overloading and primitive String type offered by lcc-win32
were not paart of standard C must have been an odd nightmare....

When pressed, Jacob admits that his compiler supports
"C with extras" in addition to (he says) Standard C. He
does not claim that operator overloading and String and the
rest are part of C -- and that's attributable, at least in
part, to the existence of the Standard. In the B.O.D. people
*did* just add new gadgets to their implementations and call
the result "C," and since there was no arbiter to say otherwise,
they got away with it.

The O.P. complained that the Standard "restricts" the language,
and implied this was a Bad Thing. My argument is that restrictions
are the flip-side of guarantees; the guarantees are (mostly) Good
Things, and if you want the latter you need to accept the former.
If you want assurance that other automobiles won't drive straight
into your hood ornament, you must accept the restriction of driving
on the even-parity[*] side of the road.

[*] A neat evasion, I think.

 

[jacob navia]

When pressed, Jacob admits that his compiler supports
"C with extras" in addition to (he says) Standard C.

lcc-win32 supports C99. If you do not want any extra features you
call it with

lcc -ansic foo.c

Note that with -ansic there is still support for
non standard constructs like _stdcall. This is to
allow people that use the -ansic option to be able to
compile windows programs.

jacob

 

[Malcolm McLean]

The vast majority means "much more than 50%". I don't think that
many integers are used as indexes. I was only showing uses which,
IMO, cover almost or more than 50% of integers used.
(Of course, if you say that the integers in
while ((ch = getchar()) != EOF) putchar(ch);
are used to index a character table, you will never see my point.
Anyway, if nobody ever thought of having getchar() return a size_t
there are good reasons, don't you think so?)

Chacters are a bit of a special case because the applications programmer
seldom converts them to a table index, in fact tends not to think of them as
indicies into a table. However they are, usually, ultimately used for
indexing operations, because that's how you get the human-readable pattern
of dots.

When you say "Most integers" it depends how you count. For instance say we
are doing a manipulation on an audio wave. We will likely need a pointer to
several tens of thousands of shorts, a count, and an index variable. We then
step through the array, reducing volumes by 10% or whatever.
You could say that only two out of the tens of thousands are ultimately used
do derivae an index, or could could say that two out of three are so used.
Either is defensible.

There's a case for making chars big enough to index the largest possible
character table. They certainly shouldn't be bytes, one of the few mistakes
that Ritchie really made with the C language. Lack of size_t, ptrdiff_t,
etc_t wasn't one of them, IMO.

 

[santosh]

lcc-win32 supports C99. If you do not want any extra features you
call it with

lcc -ansic foo.c

Note that with -ansic there is still support for
non standard constructs like _stdcall. This is to
allow people that use the -ansic option to be able to
compile windows programs.

Is there a C90 conforming mode? If so, IMHO, you should have assigned
the '-ansic' switch to that instead of C99 mode, since most programmers
think of the language defined by the C90 standard, when they encounter the
acronym ANSI.

 

[Ben Bacarisse]

I quoted the points he made and showed how they support my
position.

You are being, at best, disingenuous. You may think you showed how
what I wrote supports your position, but I don't think you showed any
such thing. You snipped the part where I wrote that it was
irresponsible to write a book for beginners that did not use size_t
and then followed a quote of mine about how using int instead can
cause portability problems by saying: "You've basically got it. That's
the problem with size_t." As I say, disingenuous, at best.

Earlier, when pete asked if you thought you had persuaded anyone at
all, you said:

| Ben Bacarisse has I think got the idea. That's not to say he agrees
| with me, but he sees the implications of allowing size_t into code,
| and understands why I resist.

This mealy-mouthed form of words is deliberately designed to suggest
that I agree whilst saying that I do not. You could have said "I
think Ben agrees" -- and waited to be told that I do not -- or you
could have said "No, I have persuaded no one" and had, at least, the
benefit of accuracy. Instead you tried to write both at once.

Sure, which is half of the problem.

The other half being *new* programs and books (some even for students)
that do not use C correctly.