HeathField Strange Ideas!

8 views
Skip to first unread message

Paul

unread,
Aug 24, 2007, 5:11:27 PM8/24/07
to
This guy 'Richard Heathfield' and a few others seem to be dictating
nonsense about the ISO standards etc and sending out the impression that
C is very restricted. For Example: There have been posts made asking for
help on basic things like simple keyboard input routines which are
quickly dismissed to be impossible to do with compliant code.

These people who seem to have the misinterpreted the standards and who
believe they are in place to hinder us have certainly got their ideas
very much wrong.

The standards are on our side and there to help us. I trust most can see
why. If the standards in some way do restrict the C language, I would
suggest that it be more usefull to correct the standards, than to
correct the C language in such a manner to make it less portable. Who
does this guy think he is?

And I have also noted he has tried to copy and enlighten on, the much
respected, Kernighan & Ritchies works. Again who does this guy think he
is?

I find utterly annoying that this person has had a book published
entitled 'C Unleashed'. This title implying that the book will teach a
programmer to write 'go anywhere code'. This persons interpretations of
the standards would infact be more restrictive. How can anyone assume
the content of this book is anything more than shredder food when the
author cannot even understand the simple oxymoron 'portable
restriction'?

Ben Pfaff

unread,
Aug 24, 2007, 5:24:28 PM8/24/07
to
Paul <pau...@mial.com> writes:

> This guy 'Richard Heathfield' and a few others seem to be dictating
> nonsense about the ISO standards etc and sending out the impression that
> C is very restricted. For Example: There have been posts made asking for
> help on basic things like simple keyboard input routines which are
> quickly dismissed to be impossible to do with compliant code.

You may be trolling. If not, you would get more to-the-point
responses if you'd give specific quotes from Richard's articles
and point out what you believe to be wrong in them. Usually,
Richard is right.
--
Here's a tip: null pointers don't have to be *dull* pointers!

Default User

unread,
Aug 24, 2007, 5:30:40 PM8/24/07
to
Paul wrote:

> This guy 'Richard Heathfield' and a few others seem to be dictating
> nonsense about the ISO standards etc and sending out the impression
> that C is very restricted. For Example: There have been posts made
> asking for help on basic things like simple keyboard input routines
> which are quickly dismissed to be impossible to do with compliant
> code.


You are incorrect.

Brian

Malcolm McLean

unread,
Aug 24, 2007, 5:44:02 PM8/24/07
to

"Paul" <pau...@mial.com> wrote in message
news:slrnfcuibh....@nospam.invalid...

> This guy 'Richard Heathfield' and a few others seem to be dictating
> nonsense about the ISO standards etc and sending out the impression that
> C is very restricted. For Example: There have been posts made asking for
> help on basic things like simple keyboard input routines which are
> quickly dismissed to be impossible to do with compliant code.
>
Compilers for hosted systems, that is to say PC type computers, always come
with libraries to handle the keybooard and screen. However they are
non-standard. Your Linux curses won't work under most Windows compilers, and
the same goes for Windows conio. Except that if you look hard enough these
two systems are common enough for there to be some workarounds and kludges
so you can actually compile programs for both systems, but it is difficult
and error-prone.

ANSI C offers only stream-based input and output. Great for playing hangman,
but useless for space invaders.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Philip Potter

unread,
Aug 24, 2007, 5:49:51 PM8/24/07
to
Paul wrote:
> This guy 'Richard Heathfield' and a few others seem to be dictating
> nonsense about the ISO standards etc and sending out the impression that
> C is very restricted. For Example: There have been posts made asking for
> help on basic things like simple keyboard input routines which are
> quickly dismissed to be impossible to do with compliant code.
>
> These people who seem to have the misinterpreted the standards and who
> believe they are in place to hinder us have certainly got their ideas
> very much wrong.

Tell me again, because it wasn't clear the first time: in what way was
Richard Heathfield's advice wrong? Be specific; if possible, quote where
the Standard contradicts his advice.

--
Philip Potter pgp <at> doc.ic.ac.uk

Eric Sosman

unread,
Aug 24, 2007, 5:51:36 PM8/24/07
to
Paul wrote On 08/24/07 17:11,:

On the assumption that you're not just trolling,
I'll attempt a point-by-point:

Some "simple" keyboard things are indeed not possible
with C's I/O facilities unless they are given help by means
outside the language definition. The task of determining
whether a key has been pressed without actually reading the
character it generates (if any) and blocking the program
until it arrives is beyond C's unaided reach. When R.H. or
anyone else tells you this, you are not being told nonsense.

Your second paragraph is purely opinion, not something
that can be debated on the basis of evidence.

The third paragraph is, I think, the crux of your
difficulty. The Standard is indeed on our side, and the way
it helps us is by putting limits -- "restrictions" -- on
how bizarre an implementation can be and still be "C." You
may not remember the Bad Old Days when everyone with what
he thought was a Good Idea promptly enshrined it in his
compiler and/or his library; it was in those days that the
jest "C combines the power of assembly language with the
portability of assembly language" was coined. It was funny
in a wry sort of way, but the reason it was funny is that
it contained a discernible nugget of truth. When the Standard
came along and decreed that sprintf() would return a character
count and not (as on some implementations) a pointer to the
generated string, this restriction made life easier for us
programmers. When the Standard decreed exactly how the
integer promotions work, instead of leaving them up to the
whim of the implementation, our tools started behaving more
predictably. We could struggle with the problem at hand,
rather than with the implementations.

Your fourth paragraph makes no sense to me; I don't
understand what you are trying to say.

The factual assertion in the fifth paragraph is that
you are annoyed. On the evidence, that seems possible.
Did the content of his "shredder food" annoy you, or are
you just annoyed as a life-style choice?

--
Eric....@sun.com

Ian Collins

unread,
Aug 24, 2007, 6:12:24 PM8/24/07
to
Paul wrote:
> This guy 'Richard Heathfield' and a few others seem to be dictating
> nonsense about the ISO standards etc and sending out the impression that
> C is very restricted. For Example: There have been posts made asking for
> help on basic things like simple keyboard input routines which are
> quickly dismissed to be impossible to do with compliant code.
>
Please provide a counter example in pure standard C, we would all
benefit greatly from this.

> These people who seem to have the misinterpreted the standards and who
> believe they are in place to hinder us have certainly got their ideas
> very much wrong.
>

Please provide an example of this misinterpretation.

> The standards are on our side and there to help us. I trust most can see
> why. If the standards in some way do restrict the C language, I would
> suggest that it be more usefull to correct the standards, than to
> correct the C language in such a manner to make it less portable. Who
> does this guy think he is?
>

Eric's rebuttal of this paragraph says it all.

> And I have also noted he has tried to copy and enlighten on, the much
> respected, Kernighan & Ritchies works. Again who does this guy think he
> is?
>

Do what?

--
Ian Collins.

Al Balmer

unread,
Aug 24, 2007, 6:15:45 PM8/24/07
to
On Fri, 24 Aug 2007 23:11:27 +0200 (CEST), Paul <pau...@mial.com>
wrote:

>I find utterly annoying that this person has had a book published
>entitled 'C Unleashed'.

<OT> I take it your book was rejected by all the publishers? </OT>

Did you have a question about C?

--
Al Balmer
Sun City, AZ

Philip Potter

unread,
Aug 24, 2007, 6:23:54 PM8/24/07
to
Malcolm McLean wrote:
>
> "Paul" <pau...@mial.com> wrote in message
> news:slrnfcuibh....@nospam.invalid...
>> This guy 'Richard Heathfield' and a few others seem to be dictating
>> nonsense about the ISO standards etc and sending out the impression that
>> C is very restricted. For Example: There have been posts made asking for
>> help on basic things like simple keyboard input routines which are
>> quickly dismissed to be impossible to do with compliant code.
>>
> Compilers for hosted systems, that is to say PC type computers, always
> come with libraries to handle the keybooard and screen. However they are
> non-standard.

I'm not normally one to quibble on wording, but I thought a hosted
implementation was a very specific thing: namely, a C implementation
which also provides the C standard library and starts a program with
"int main(void)" or "int main(int, char**)" (and possibly more
restrictions that I don't know about). Nothing to do with PC-like
computers or having a keyboard and mouse.

In fact I've got a C implementation which provides the standard library
functions but is certainly not PC-like and has neither keyboard nor
mouse. stdin and stdout connect to an RS-232 port.

Phil

Keith Thompson

unread,
Aug 24, 2007, 6:39:06 PM8/24/07
to
Paul <pau...@mial.com> writes:
[...]

> Who does this guy think he is?

He thinks he's Richard Heathfield. Who does he have to be? And who
the heck are you?

--
Keith Thompson (The_Other_Keith) ks...@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"

jacob navia

unread,
Aug 24, 2007, 8:22:11 PM8/24/07
to
Paul wrote:
> This guy 'Richard Heathfield' and a few others seem to be dictating
> nonsense about the ISO standards etc and sending out the impression that
> C is very restricted. For Example: There have been posts made asking for
> help on basic things like simple keyboard input routines which are
> quickly dismissed to be impossible to do with compliant code.
>

They are just pedants. Do not worry. Not everyone is like them here.

> These people who seem to have the misinterpreted the standards and who
> believe they are in place to hinder us have certainly got their ideas
> very much wrong.
>
> The standards are on our side and there to help us. I trust most can see
> why. If the standards in some way do restrict the C language, I would
> suggest that it be more usefull to correct the standards, than to
> correct the C language in such a manner to make it less portable. Who
> does this guy think he is?
>
> And I have also noted he has tried to copy and enlighten on, the much
> respected, Kernighan & Ritchies works. Again who does this guy think he
> is?
>

He think he is the pope, and many people here believe that, maybe
because some people *need* a pope to rely on. Much easier than using
the brain...

> I find utterly annoying that this person has had a book published
> entitled 'C Unleashed'. This title implying that the book will teach a
> programmer to write 'go anywhere code'. This persons interpretations of
> the standards would infact be more restrictive. How can anyone assume
> the content of this book is anything more than shredder food when the
> author cannot even understand the simple oxymoron 'portable
> restriction'?
>

It is a good book, with some bugs as any other book, but in
general useful.

Philip Potter

unread,
Aug 24, 2007, 8:38:48 PM8/24/07
to
jacob navia wrote:
> Paul wrote:
>> This guy 'Richard Heathfield' and a few others seem to be dictating
>> nonsense about the ISO standards etc and sending out the impression that
>> C is very restricted. For Example: There have been posts made asking for
>> help on basic things like simple keyboard input routines which are
>> quickly dismissed to be impossible to do with compliant code.
>
> They are just pedants. Do not worry. Not everyone is like them here.

But one must maintain a certain amount of pedantry to be sure of
sticking to the C standard and writing portable code. Naturally, it is
not always necessary, possible or desirable to write portable code, but
most of the time it is all three.

The comp.lang.c FAQ, question 19.1 covers a part of this topic.

>> These people who seem to have the misinterpreted the standards and who
>> believe they are in place to hinder us have certainly got their ideas
>> very much wrong.
>>
>> The standards are on our side and there to help us. I trust most can see
>> why. If the standards in some way do restrict the C language, I would
>> suggest that it be more usefull to correct the standards, than to
>> correct the C language in such a manner to make it less portable. Who
>> does this guy think he is?
>>
>> And I have also noted he has tried to copy and enlighten on, the much
>> respected, Kernighan & Ritchies works. Again who does this guy think he
>> is?
>>
>
> He think he is the pope, and many people here believe that, maybe
> because some people *need* a pope to rely on. Much easier than using
> the brain...

I for one do not think Richard Heathfield is the Pope. I don't take what
he says as gospel - in fact, I frequently question him and his advice
when I find aspects of it questionable - sometimes because he makes
mistakes, sometimes because his code style is different from mine.
Nevertheless it is a fact that I have learned huge amounts from him and
his pedantry - quite a bit more than I have learned from his most vocal
critics.

He has my respect because he has earned it.

Ian Collins

unread,
Aug 24, 2007, 8:58:07 PM8/24/07
to
Philip Potter wrote:
> jacob navia wrote:
>> Paul wrote:
>>> This guy 'Richard Heathfield' and a few others seem to be dictating
>>> nonsense about the ISO standards etc and sending out the impression that
>>> C is very restricted. For Example: There have been posts made asking for
>>> help on basic things like simple keyboard input routines which are
>>> quickly dismissed to be impossible to do with compliant code.
>>
>> They are just pedants. Do not worry. Not everyone is like them here.

The best pedant I know is a compliant compiler in compliant mode...


>
> But one must maintain a certain amount of pedantry to be sure of
> sticking to the C standard and writing portable code. Naturally, it is
> not always necessary, possible or desirable to write portable code, but
> most of the time it is all three.
>

I'm not a pedant, I tend to be lazy and slack, so I always make sure I
have at least one pedantic developer in my team. Without pedantic
developers and engineers we wouldn't have standards and the world as we
know it would fall apart in short order.


>>
>> He think he is the pope, and many people here believe that, maybe
>> because some people *need* a pope to rely on. Much easier than using
>> the brain...
>
> I for one do not think Richard Heathfield is the Pope. I don't take what
> he says as gospel - in fact, I frequently question him and his advice
> when I find aspects of it questionable - sometimes because he makes
> mistakes, sometimes because his code style is different from mine.
> Nevertheless it is a fact that I have learned huge amounts from him and
> his pedantry - quite a bit more than I have learned from his most vocal
> critics.
>
> He has my respect because he has earned it.
>

+1 to the above form me.

--
Ian Collins.

pete

unread,
Aug 24, 2007, 10:01:15 PM8/24/07
to
Paul wrote:
>
> This guy 'Richard Heathfield' and a few others seem to be dictating
> nonsense about the ISO standards etc
> and sending out the impression that C is very restricted.
> For Example: There have been posts made asking for
> help on basic things like simple keyboard input routines which are
> quickly dismissed to be impossible to do with compliant code.

I hate that guy.
Every time he sees a mistake in one of my posts,
he corrects it!
And those few others, are no better.

> These people who seem to have the misinterpreted the standards
> and who believe they are in place to hinder us
> have certainly got their ideas very much wrong.

It's wrong because it's like against society.
It's wrong because everybody has the right to live
and be happy without being tolchocked and knifed.

--
pete

Default User

unread,
Aug 24, 2007, 10:27:44 PM8/24/07
to
Philip Potter wrote:

> jacob navia wrote:

> > He think he is the pope, and many people here believe that, maybe

> > because some people need a pope to rely on. Much easier than using


> > the brain...
>
> I for one do not think Richard Heathfield is the Pope.


Certainly not. For instance, I think RH argues with that moron Navia
too much.


Brian

Christopher Benson-Manica

unread,
Aug 24, 2007, 10:51:24 PM8/24/07
to
[comp.lang.c] jacob navia <ja...@jacob.remcomp.fr> wrote:

> Paul wrote:
>> This guy 'Richard Heathfield' and a few others seem to be dictating
>> nonsense about the ISO standards

Sounds like someone has called gets() one too many times. That would
explain the garbage output.

> They are just pedants. Do not worry. Not everyone is like them here.

True enough; some people are wrong much more often.

> He think he is the pope, and many people here believe that, maybe
> because some people *need* a pope to rely on. Much easier than using
> the brain...

I suspect that Mr. Heathfield has far too much self-respect to ever
accuse himself of being the Pope.

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.

jaysome

unread,
Aug 25, 2007, 3:27:31 AM8/25/07
to
On Fri, 24 Aug 2007 23:11:27 +0200 (CEST), Paul <pau...@mial.com>
wrote:

>This guy 'Richard Heathfield' and a few others seem to be dictating


>nonsense about the ISO standards etc and sending out the impression that
>C is very restricted. For Example: There have been posts made asking for
>help on basic things like simple keyboard input routines which are
>quickly dismissed to be impossible to do with compliant code.

Saying that someone who "seems" to be sending out the impression that
C is very restricted and by doing so implies they are dictating
nonsense about the ISO standards "seems" to me a very subjective
opinion. Don't you agree? Put another way: Don't you "seem" to agree?
I certainly agree.

>These people who seem to have the misinterpreted the standards and who
>believe they are in place to hinder us have certainly got their ideas
>very much wrong.

Again, you say that these people "seem" to have the [sic]
misinterpreted the standards. I certainly agree that they did
interpret them correctly (and if they did not, other respectable
members here in this newsgroup corrected them, and in most if not all
cases the misinterpreter responded with a sheepish reply that invoked
images of a tail between the legs--we're all human).

>The standards are on our side and there to help us. I trust most can see
>why. If the standards in some way do restrict the C language, I would
>suggest that it be more usefull to correct the standards, than to
>correct the C language in such a manner to make it less portable. Who
>does this guy think he is?

The standards are indeed on our side. That's why they allow you to do
silly stuff like:

int i = 0;
i = i++;

and for the implementation to define functions like:

int _kbhit( void );

>And I have also noted he has tried to copy and enlighten on, the much
>respected, Kernighan & Ritchies works. Again who does this guy think he
>is?

He's not the only one. K&R is considered a respected work by most if
not all C afficionados.

>I find utterly annoying that this person has had a book published
>entitled 'C Unleashed'. This title implying that the book will teach a
>programmer to write 'go anywhere code'. This persons interpretations of
>the standards would infact be more restrictive. How can anyone assume
>the content of this book is anything more than shredder food when the
>author cannot even understand the simple oxymoron 'portable
>restriction'?

My copy of "C Unleashed" (note the C-style quotations, not the
MATLAB-style ones) says or notes nothing whatsoever about teaching a
programmer to write "go anywhere code" (again, note the C-style
quotations, not the MATLAB-style ones). If your copy says such a
thing, can you please tell us what page number it is cited on?

I've learned a lot from Richard's posts. And I know that if I am ever
in a C programmer interview situation and the interviewer asks me a
question like "What is a good way of furthering you knowledge about
Standard C?", and one of the choices is "Do a Google newsgroups search
for "Richard Heathfield" in comp.lang.c, I know what the correct
answer is. And, of course, YMMV :^)

Best regards
--
jay

Malcolm McLean

unread,
Aug 25, 2007, 5:33:15 AM8/25/07
to

"Ian Collins" <ian-...@hotmail.com> wrote in message
news:5j9d4vF3...@mid.individual.net...

> Philip Potter wrote:
> I'm not a pedant, I tend to be lazy and slack, so I always make sure I
> have at least one pedantic developer in my team. Without pedantic
> developers and engineers we wouldn't have standards and the world as we
> know it would fall apart in short order.

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. They are in
the standard as the correct way to hold a size and pointer difference,
therefore they are right. To a point, he is correct, but no-one is going to
use a language where an arbitrary array index is called size_t. It seize_t's
everything up.

The problem then is that the guy who can see ahead is accused of not knowing
the standard and his works condemned. Heathfield is more a Prefect for the
Congregation of the Doctrine of the Faith than Pope, which is OK, as long
the committee is infallible. But it is not, it's decrees are widely ignored
as absurd, its constructs deprecated by the likes of Microsoft, even Denis
Ritchie has spoken out against its const, though he did get his way on
noalias.

However that doesn't mean he is not a respected and valued member of the
group. He is.

Army1987

unread,
Aug 25, 2007, 5:52:15 AM8/25/07
to
On Sat, 25 Aug 2007 10:33:15 +0100, Malcolm McLean wrote:

>
> "Ian Collins" <ian-...@hotmail.com> wrote in message
> news:5j9d4vF3...@mid.individual.net...
>> Philip Potter wrote:
>> I'm not a pedant, I tend to be lazy and slack, so I always make sure I
>> have at least one pedantic developer in my team. Without pedantic
>> developers and engineers we wouldn't have standards and the world as we
>> know it would fall apart in short order.
>
> 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. They are in
> the standard as the correct way to hold a size and pointer difference,
> therefore they are right. To a point, he is correct, but no-one is going to
> use a language where an arbitrary array index is called size_t. It seize_t's
> everything up.

What on earth are you speaking about? You can index an array with
whatever integral value you like most.
--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

Philip Potter

unread,
Aug 25, 2007, 6:11:52 AM8/25/07
to
Malcolm McLean wrote:
> 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. They
> are in the standard as the correct way to hold a size and pointer
> difference, therefore they are right. To a point, he is correct, but
> no-one is going to use a language where an arbitrary array index is
> called size_t. It seize_t's everything up.

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

> The problem then is that the guy who can see ahead is accused of not
> knowing the standard and his works condemned. Heathfield is more a
> Prefect for the Congregation of the Doctrine of the Faith than Pope,
> which is OK, as long the committee is infallible. But it is not, it's
> decrees are widely ignored as absurd, its constructs deprecated by the
> likes of Microsoft, even Denis Ritchie has spoken out against its const,
> though he did get his way on noalias.

Having read http://www.lysator.liu.se/c/dmr-on-noalias.html, it seems
like he got his way on const, too.

Phil

Malcolm McLean

unread,
Aug 25, 2007, 6:58:44 AM8/25/07
to

"Philip Potter" <p...@see.sig.invalid> wrote in message
news:faov99$75e$1...@aioe.org...

> Malcolm McLean wrote:
>> 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. They are in
>> the standard as the correct way to hold a size and pointer difference,
>> therefore they are right. To a point, he is correct, but no-one is going
>> to use a language where an arbitrary array index is called size_t. It
>> seize_t's everything up.
>
> 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

unread,
Aug 25, 2007, 6:59:28 AM8/25/07
to
Malcolm McLean wrote:
>
> "Ian Collins" <ian-...@hotmail.com> wrote in message
> news:5j9d4vF3...@mid.individual.net...
>> Philip Potter wrote:
>> I'm not a pedant, I tend to be lazy and slack, so I always make sure I
>> have at least one pedantic developer in my team. Without pedantic
>> developers and engineers we wouldn't have standards and the world as we
>> know it would fall apart in short order.
>
> The problem is that pedantry can blind you to real issues.
>
That's why I said "in my team", team is important.

--
Ian Collins.

pete

unread,
Aug 25, 2007, 7:15:15 AM8/25/07
to
Malcolm McLean wrote:
>
> "Ian Collins" <ian-...@hotmail.com> wrote in message
> news:5j9d4vF3...@mid.individual.net...
> > Philip Potter wrote:
> > I'm not a pedant, I tend to be lazy and slack, so I always make sure I
> > have at least one pedantic developer in my team. Without pedantic
> > developers and engineers we wouldn't have standards and the world as we
> > know it would fall apart in short order.
>
> 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?

--
pete

Spiros Bousbouras

unread,
Aug 25, 2007, 7:49:27 AM8/25/07
to

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

unread,
Aug 25, 2007, 7:53:14 AM8/25/07
to
On Sat, 25 Aug 2007 11:58:44 +0100, Malcolm McLean wrote:

>
> "Philip Potter" <p...@see.sig.invalid> wrote in message
> news:faov99$75e$1...@aioe.org...
>> Malcolm McLean wrote:
>>> 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. They are in
>>> the standard as the correct way to hold a size and pointer difference,
>>> therefore they are right. To a point, he is correct, but no-one is going
>>> to use a language where an arbitrary array index is called size_t. It
>>> seize_t's everything up.
>>
>> 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).

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

unread,
Aug 25, 2007, 8:22:49 AM8/25/07
to

"Army1987" <army...@NOSPAM.it> wrote in message
news:pan.2007.08.25....@NOSPAM.it...
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

unread,
Aug 25, 2007, 8:26:46 AM8/25/07
to

"pete" <pfi...@mindspring.com> wrote in message
news:46D00F...@mindspring.com...

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

unread,
Aug 25, 2007, 9:55:24 AM8/25/07
to
"Malcolm McLean" <regn...@btinternet.com> writes:

> "pete" <pfi...@mindspring.com> wrote in message
> news:46D00F...@mindspring.com...
>>> 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?
>>
> 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.

--
Ben.

Malcolm McLean

unread,
Aug 25, 2007, 2:03:01 PM8/25/07
to

"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:871wdr4...@bsb.me.uk...
> "Malcolm McLean" <regn...@btinternet.com> 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

unread,
Aug 25, 2007, 5:52:42 PM8/25/07
to
>>>>> "ES" == Eric Sosman <Eric....@sun.com> writes:

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


--
Charlton Wilbur
cwi...@chromatico.net

Ben Bacarisse

unread,
Aug 25, 2007, 8:21:57 PM8/25/07
to
"Malcolm McLean" <regn...@btinternet.com> writes:

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.

--
Ben.

Malcolm McLean

unread,
Aug 25, 2007, 8:27:42 PM8/25/07
to

"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:87ir732...@bsb.me.uk...
I specifically said you didn't agree with me. At least you disagree, which
is an advance.

Richard

unread,
Aug 25, 2007, 8:35:33 PM8/25/07
to
"Malcolm McLean" <regn...@btinternet.com> writes:

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

unread,
Aug 25, 2007, 8:54:31 PM8/25/07
to

"Richard" <rgr...@gmail.com> wrote in message
news:01fy27c...@homelinux.net...

> "Malcolm McLean" <regn...@btinternet.com> writes:
>> 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.
>
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

unread,
Aug 26, 2007, 6:19:44 AM8/26/07
to

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

unread,
Aug 26, 2007, 8:31:03 AM8/26/07
to
Charlton Wilbur wrote:
>>>>>> "ES" == Eric Sosman <Eric....@sun.com> writes:
>
> 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.

--
Eric Sosman
eso...@ieee-dot-org.invalid

jacob navia

unread,
Aug 26, 2007, 8:37:03 AM8/26/07
to
Eric Sosman wrote:
> 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

unread,
Aug 26, 2007, 11:33:00 AM8/26/07
to

"Army1987" <army...@NOSPAM.it> wrote in message
news:pan.2007.08.26....@NOSPAM.it...

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

unread,
Aug 26, 2007, 1:49:47 PM8/26/07
to
jacob navia wrote:

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

unread,
Aug 26, 2007, 1:59:35 PM8/26/07
to
"Malcolm McLean" <regn...@btinternet.com> writes:

> "Richard" <rgr...@gmail.com> wrote in message
> news:01fy27c...@homelinux.net...
>> "Malcolm McLean" <regn...@btinternet.com> writes:
>>> 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.
>>
> 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.

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

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

--
Ben.

Eric Sosman

unread,
Aug 26, 2007, 2:08:18 PM8/26/07
to
santosh wrote:

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

If the extensions all involve the use of reserved
identifiers like _stdcall, conformance to "ANSI" is
not threatened.

--
Eric Sosman
eso...@ieee-dot-org.invalid

Al Balmer

unread,
Aug 26, 2007, 4:49:17 PM8/26/07
to
On Sun, 26 Aug 2007 12:19:44 +0200, Army1987 <army...@NOSPAM.it>
wrote:

>On Sat, 25 Aug 2007 13:22:49 +0100, Malcolm McLean wrote:
>

<snip>


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

It doesn't matter. We talk about C programming here, not statistics.
If Mr. McLean doesn't like the C language, surely he can find
something else among the thousands of languages that have been
invented. Perhaps there's even one whose types are based on the
frequency with which they're needed.

--
Al Balmer
Sun City, AZ

Keith Thompson

unread,
Aug 26, 2007, 8:34:30 PM8/26/07
to

You've said that lcc-win32 does not support all C99 features. IMHO
you should have mentioned that rather than claiming without
qualification that "lcc-win32 supports C99".

Any conforming C90 compiler supports a large subset of C99. lcc-win32
apparently supports a somewhat larger subset of C99.

You might consider suporting a *strict* ISO C mode, in which
extensions (even ones allowed by the standard) are disabled. This
would make it easier for users to determine whether the code they're
compiling is potentially portable to other implementations.

--
Keith Thompson (The_Other_Keith) ks...@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"

Malcolm McLean

unread,
Aug 27, 2007, 5:23:27 AM8/27/07
to

"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:87ejhqg...@bsb.me.uk...

> 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.
>
I don't think there's anything mealy mouthed about that. Not all questions
can be answered yes/no. In fact if someone demands "a simple yes or a simple
no" there's usually something wrong with the question in some way.

Philip Potter

unread,
Aug 27, 2007, 5:37:57 AM8/27/07
to

AIUI _stdcall isn't reserved, only __stdcall is. (And _Stdcall, though I've
never seen that used.)

Michal Nazarewicz

unread,
Aug 27, 2007, 6:46:46 AM8/27/07
to
Paul <pau...@mial.com> writes:
> If the standards in some way do restrict the C language, I would
> suggest that it be more usefull to correct the standards, than to
> correct the C language in such a manner to make it less portable. Who
> does this guy think he is?

Firstly, the standard does not restrict the language -- you can have
a routine to access keyboard in given implementation. Standard only
specifies the minimal requirements implementation have to fulfil.

In fact adding additional requirements would make language less
portable. For instance how do you want to read a key from keyboard on
a microprocessor which has no keyboard is attached to? Or clear a screen
where no screen is available?

If you want you can go complaining to OS vendors that they have no
common standard for controlling keyboard or screen. You can go to
Microsoft and ask why Windows does not implement POSIX standard or you
can go to any Unix/Unix-like OS vendor and ask why they have different
functions then Windows have.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--

Michal Nazarewicz

unread,
Aug 27, 2007, 7:00:38 AM8/27/07