HeathField Strange Ideas!
Paul
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
> 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
> 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
"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.
>
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
> 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
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?
Ian Collins
> 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.
>
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
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
>
> "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
[...]
> 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
> 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
> 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
> 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
>
> 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
> 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
> 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
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
"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
>
> "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
> 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
"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.
>
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
>
> "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.
>
--
Ian Collins.
pete
>
> "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
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
>
> "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
"Army1987" <army...@NOSPAM.it> wrote in message
news:pan.2007.08.25....@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.
Malcolm McLean
"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?
>
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
> "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
"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
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
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
is an advance.
Richard
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
"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.
>
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.
>
Army1987
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" == 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
> 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
"Army1987" <army...@NOSPAM.it> wrote in message
>> 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?)
>
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
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
> "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
> 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
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
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
> 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.
>
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
AIUI _stdcall isn't reserved, only __stdcall is. (And _Stdcall, though I've
never seen that used.)
Michal Nazarewicz
> 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
> 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.
Not true. If you thing about abstract algorithms then you may be
right, however, you may not forget that abstract algorithms are useless
if you do not store any data and data in many cases can be integers,
ie. bank account balance, geographic coordinates where positive numbers
are East/North and negative West/South, temperatures in Scotland in
January 2006...
> 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.
With this way of thinking you should also remove "const" from
C language. I have seen quit a few C projects which almost never use it
(ie. functions which analyse strings take "char *" as an argument
instead of "const char *"). I believe that there are more things that
people are inconsistent in using.
> 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.
If Fred wants a list of ints and Jim a list of size_ts then one of them
thinks that this list is something different then it in fact is. If
both Fred and Jim were consistent they would choose single type to use
for list's elements.
Ben Bacarisse
_stdcall is reserved as an identifier at file scope (both as an
ordinary identifier and as a tag name). The upshot is that an
implementation can do what it likes with _stdcall provided that it
doses not interfere with the name being used as a macro or as an id
*not* at file scope.
As you say, __stdcall and _Stdcall are reserved for all uses.
--
Ben.
Eric Sosman
Thanks for the correction. It turns out _stdcall is
reserved, but only at file scope. The programmer must not
use _stdcall as an identifier outside a function, but may
use it in a function argument list or inside a function's body.
Or, turning things around, the compiler can recognize _stdcall
as something special if it appears at file scope, but must
not give it special treatment elsewhere.
--
Eric Sosman
eso...@ieee-dot-org.invalid
jacob navia
This compiles under lcc-win32:
void _stdcall fn(void)
{
int _stdcall=0;
}
The semantics are as you would expect.
MSVC produces:
tstdcall.c(3) : error C2059: syntax error : ';'
jacob navia
void _stdcall fn(void)
{
int _stdcall=0;
}
The semantics are as you would expect.
MSVC produces:
tstdcall.c(3) : error C2059: syntax error : ';'
jacob
Christopher Benson-Manica
> 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.
Is the behavior of the following program defined or not?
int main(void) {
return 0;
}
How about this one?
int main(void) {
printf("Yes or no?\n");
return 0;
}
Would you care to explain what is wrong with these questions? Or, for
that matter, with "Does X agree with Y's contentions or not?"
--
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.
Walter Roberson
Christopher Benson-Manica <at...@otaku.freeshell.org> wrote:
>[comp.lang.c] Malcolm McLean <regn...@btinternet.com> wrote:
>> 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.
>Is the behavior of the following program defined or not?
>int main(void) {
> return 0;
>}
The behaviour is defined until the return statement is processed,
but no further. The return value of 0 is -intended- to specify
a "successful" execution, but C leaves undefined what that
actually means. In some OS's, the "succesful" return
of this do-nothing program could, for example, lock all of a
city's traffic lights on "flashing red" -- as, in context, -any-
return from the program might be unusual or unexpected
or supposedly not possible and "flashing red" might be the
hardware fail-safe.
But if you were to define what the OS will do when it gets
a successful return, then we could tell you what the effect
of running the program would be. So "it depends".
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
Christopher Benson-Manica
> In article <faurpv$l2h$1...@chessie.cirr.com>,
> Christopher Benson-Manica <at...@otaku.freeshell.org> wrote:
>>Is the behavior of the following program defined or not?
>>int main(void) {
>> return 0;
>>}
> The behaviour is defined until the return statement is processed,
> but no further.
Aside from the fact that the question (apparently) ought to have been
"Is the following program strictly conforming or not?", it seems
rather useless to note that the behavior of the program is not defined
once it has ceased executing. The question IMO clearly specifies
interest in what the *program* does, and not what the OS might do
after a "successful" program execution.
Kelsey Bjarnason
On Sat, 25 Aug 2007 11:58:44 +0100, Malcolm McLean wrote:
> 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,
Size_t is, last I checked, an unsigned integer type. This would be most
improper for anything involving negative values:
size_t x = -2;
size_t y = -3;
What's the result of x + y? Is it -5? Not here it ain't.
Next.
Kelsey Bjarnason
On Sat, 25 Aug 2007 19:03:01 +0100, Malcolm McLean wrote:
>> [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.
> That's the problem with size_t.
> If we were forced to use size_t all the time
Then code would break, as demonstrated elsewhere.
> the objection would be
> merely to its ugly spelling and unsignedness.
You often need to get the -3rd element of a buffer, do you?
> As it is it a poison that
> propagates through code, destroying the compatibility of functions with
> each other
Odd, I don't see this happening. I also note you don't demonstrate an
actual case of it.
> , because most people will still e int where strictly it
> should be a size_t.
Who is "most people"? Most C programmers I'm aware of actually use size_t
when dealing with buffers and the like, as size_t is the proper type.
The only one, in fact, I see regularly using int - and thus producing
broken code - is *you*.
Richard Heathfield
Next is:
#include <stdio.h>
int main(void)
{
size_t x = -2;
size_t y = -3;
size_t z = -5;
if(x + y == z)
{
puts("Here, however, it is. :-)");
}
else
{
puts("Here neither.");
}
return 0;
}
--
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
Malcolm McLean
"Christopher Benson-Manica" <at...@otaku.freeshell.org> wrote in message
news:faurpv$l2h$1...@chessie.cirr.com...
> [comp.lang.c] Malcolm McLean <regn...@btinternet.com> wrote:
>
>> 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.
>
> Is the behavior of the following program defined or not?
>
> int main(void) {
> return 0;
> }
>
> How about this one?
>
> int main(void) {
> printf("Yes or no?\n");
> return 0;
> }
>
> Would you care to explain what is wrong with these questions? Or, for
> that matter, with "Does X agree with Y's contentions or not?"
>
^^^^^
You can create a question which has a "simple yes or a simple no" answer.
Those who demand "a simple yes or a simple no" as an answer usually have
defective questions, like "is C++ better than C, yes or no?". Of course you
can't answer that, it depends on the problem you are trying to solve with
the program.
Kenneth Brody
[...]
> 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.
Well, what is the definition of a "C compiler"? I assume that it
means it will properly compile any conforming C program. I do not
assume that it means it will fail to compile any and all non-
conforming programs, nor that it contains no extensions to the
Standard.
My *nix boxes have perfectly good C compilers on them, even though
I can open() files and communicate via TCP/IP sockets. I believe
that the man pages on these "extra" features don't state that they
are part of ANSI C, but rather that they are part of some other
standard (if appropriate), or that they are an extension from some
other source.
I don't believe that they need to be called "C (with extras)
compilers".
On the other hand, I see the OP has not posted any replies to this
thread as of yet, over 2-1/2 days later.
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsA...@gmail.com>
user923005
> 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.
Main Entry: ped·ant
Pronunciation: 'pe-d&nt
Function: noun
Etymology: Middle French, from Italian pedante
1 obsolete : a male schoolteacher
2 a : one who makes a show of knowledge b : one who is unimaginative
or who unduly emphasizes minutiae in the presentation or use of
knowledge c : a formalist or precisionist in teaching
Concering meaning c), I will have to agree with you. Of course in a
technical field like computer programming, getting things precisely
right is very important.
> > 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...
He's not the Pop, there's only one Dan Pop. When Dan Pop isn't
around, I still have my copy of the ANSI/ISO standard (which is almost
as good).
> > 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.
To the casual reader of this thread:
You will find the defenders of Richard Heathfield are those that
understand the C language and the detractors are generally
nincompoops.
IMO-YMMV.
Keith Thompson
> [comp.lang.c] Walter Roberson <robe...@ibd.nrc-cnrc.gc.ca> wrote:
>> In article <faurpv$l2h$1...@chessie.cirr.com>,
>> Christopher Benson-Manica <at...@otaku.freeshell.org> wrote:
>
>>>Is the behavior of the following program defined or not?
>
>>>int main(void) {
>>> return 0;
>>>}
>
>> The behaviour is defined until the return statement is processed,
>> but no further.
Right. The behavior *of the program* is defined. The behavior of the
operating system after the program terminates is irrelevant to the
question.
> Aside from the fact that the question (apparently) ought to have been
> "Is the following program strictly conforming or not?",
Huh? Those are two different questions, both valid (and the answer to
both is "yes"). Why should one question have been asked rather than
the other?
[snip]
Keith Thompson
> 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.
Yes, the standard does restrict the language in many ways. For
example, an implementation can't yield the value 5 for the expression
2+2.
Walter Roberson
Keith Thompson <ks...@mib.org> wrote:
>Christopher Benson-Manica <at...@otaku.freeshell.org> writes:
>> [comp.lang.c] Walter Roberson <robe...@ibd.nrc-cnrc.gc.ca> wrote:
>>> In article <faurpv$l2h$1...@chessie.cirr.com>,
>>> Christopher Benson-Manica <at...@otaku.freeshell.org> wrote:
>>>>Is the behavior of the following program defined or not?
>>>>int main(void) {
>>>> return 0;
>>>>}
>>> The behaviour is defined until the return statement is processed,
>>> but no further.
>Right. The behavior *of the program* is defined. The behavior of the
>operating system after the program terminates is irrelevant to the
>question.
But by that reasoning, we have no grounds for telling people that
they ought to be returning a value explicitly in C89 programs.
The relevant clause of C89 leaves it unspecified as to what happens
if no value is returned, which means it is up to the operating system
as to what happens, which is *exactly* the same case as if one
of the defined statuses -is- returned.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
Christopher Benson-Manica
> Christopher Benson-Manica <at...@otaku.freeshell.org> writes:
>> Aside from the fact that the question (apparently) ought to have been
>> "Is the following program strictly conforming or not?",
> Huh? Those are two different questions, both valid (and the answer to
> both is "yes"). Why should one question have been asked rather than
> the other?
Because I intended to ask a question whose answer was not debatable,
for rhetorical purposes. I seem to have failed with the original
question.
Malcolm McLean
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnhcmk4...@nuthaus.mib.org...
> Christopher Benson-Manica <at...@otaku.freeshell.org> writes:
>> [comp.lang.c] Walter Roberson <robe...@ibd.nrc-cnrc.gc.ca> wrote:
>>> In article <faurpv$l2h$1...@chessie.cirr.com>,
>>> Christopher Benson-Manica <at...@otaku.freeshell.org> wrote:
>>
>>>>Is the behavior of the following program defined or not?
>>
>>>>int main(void) {
>>>> return 0;
>>>>}
>>
>>> The behaviour is defined until the return statement is processed,
>>> but no further.
>
> Right. The behavior *of the program* is defined. The behavior of the
> operating system after the program terminates is irrelevant to the
> question.
>
For an average program, the questioner probably wants to know whether it
will function as expected under any conforming implementation. it would be
excessively precise to detail what happens on startup and termination.
However when a program does nothing, all that can be observed is the startup
and termination. So if someone says "will this do the same thing on my Mac
as my Windows Vista machine?", you might well give a different answer. If
they say "is the behaviour defined?" you've got to work out whether they
really know what the C standard means by "defined behaviour" or are just
using the word because they think that's how software engineers talk.
If you have to give a yes/no answer the answer is "yes", but only because it
is a toy question designed to have a yes/no answer. If it came up in
non-example context a useful answer would be more nuanced.
Christopher Benson-Manica
The behavior of the OS after program termination was not in the domain
of the question, but that does not mean that it shouldn't be of
interest to the programmer. Isn't "an implementation-defined form of
the status 'successful termination'" (n869 7.20.4.3 p5) (or at worst
an implementation-defined return status) an improvement over an
unspecified return status? (The word "exactly" doesn't seem to apply
here, unless I'm missing something.)
Christopher Benson-Manica
> "Christopher Benson-Manica" <at...@otaku.freeshell.org> wrote in message
> news:faurpv$l2h$1...@chessie.cirr.com...
>> [comp.lang.c] Malcolm McLean <regn...@btinternet.com> wrote:
>>
>>> 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.
>>
> usually
> ^^^^^
I rather doubt that there is a significant positive correlation
between a question having a "yes-no" answer and it being "defective".
> You can create a question which has a "simple yes or a simple no" answer.
> Those who demand "a simple yes or a simple no" as an answer usually have
> defective questions, like "is C++ better than C, yes or no?".
Obviously, that is a silly question. What's less obvious is why the
yes-no question of whether Mr. Bacarisse agrees with you or not is
"defective", which seems to be the point that is under contention.
Eric Sosman
> Eric Sosman wrote:
> [...]
>
>> 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.
>
> [...]
>
> Well, what is the definition of a "C compiler"? I assume that it
> means it will properly compile any conforming C program. I do not
> assume that it means it will fail to compile any and all non-
> conforming programs, nor that it contains no extensions to the
> Standard.
The Standard defines C implementations.
... and that's my point: Without the definitions (which
the O.P. thinks of as restrictions), you get anarchy. This
is no ivy-covered ivory-tower prediction, but based on
actual experience: We *did* get anarchy.
The Standard says that strchr() and its friends are
declared in <string.h>. It does not forbid an implementation
from providing a <strings.h> header in addition, but it saves
the programmer from having to write
#if defined(PLATFORM_X) || defined(PLATFORM_Y)
#include <strings.h>
#else
#include <string.h>
#endif
Yes, we had to do this -- and worse -- in the Bad Old Days.
Now, we don't need to.
The Standard gives the rules for macro substitution, so
we no longer need to worry that the insides of a string
literal will be macro-replaced, as we did in the B.O.D.
The Standard promises that free(NULL) is safe, which was
not always so in the B.O.D. The Standard requires sprintf()
to return a count; some in the B.O.D. returned a pointer.
The Standard separates the names of one struct's elements from
those of another struct; B.O.D. C compilers varied in this
regard. And so on, and so on: the Standard "restricts the
language" in order to define it, and thus give the programmer
a chance to do more programming and less porting.
I do not claim that the Standard has made a bed of roses
for programmers, but I *do* say that it has removed an awful
lot of the thorns. It has restricted us from feeling those
thorns in inconvenient parts of our anatomies.
> My *nix boxes have perfectly good C compilers on them, even though
> I can open() files and communicate via TCP/IP sockets. I believe
> that the man pages on these "extra" features don't state that they
> are part of ANSI C, but rather that they are part of some other
> standard (if appropriate), or that they are an extension from some
> other source.
>
> I don't believe that they need to be called "C (with extras)
> compilers".
>
> On the other hand, I see the OP has not posted any replies to this
> thread as of yet, over 2-1/2 days later.
From the first I thought he might be a troll, but amid
all the foolishness there was what seemed to be an actual
frustration with the "restrictions" imposed by the Standard.
But now I'm starting to think I should have sent the Three
Billy Goats Gruff in his direction.
Keith Thompson
The status value returned by a program is part of its behavior. The
above program returns a well-defined status value. Its effect on the
environment is not entirely well-defined, but it's as close to it as
you can get.
Reaching the closing '}' of main in C90 returns an undefined status
value to the environment. I don't *think* that qualifies as
"undefined behavior"; it could be argued either way. But the point
was to ask a question with a clear and unambiguous yes or no answer.
I'll also note that the question was about the behavior *of the
program*, not the behavior of the environment. The behavior of the
program is defined. Questions about the subsequent behavior of the
environment are outside the narrow scope of the question, but within
the scope of the C standard and of good programming practice.
Francin...@googlemail.com
> Kenneth Brody wrote On 08/27/07 13:45,:
> > thread as of yet, over 2-1/2 days later.
>
> From the first I thought he might be a troll, but amid
> all the foolishness there was what seemed to be an actual
> frustration with the "restrictions" imposed by the Standard.
> But now I'm starting to think I should have sent the Three
> Billy Goats Gruff in his direction.
I don't necessarily think a supply of fresh trolls is categorically a
bad thing... a discussion is no less interesting or useful to its
participants and readers because it happened to be started by a troll.
Much worse, in my opinion, are
a) persistent trolls who keep harping on about one thing, unlike the
one-off troll who sometimes chances on an interesting topic (we've
seen two examples in this very thread)
b) "serious" posters who in fact contribute absolutely nothing except
a stream of whinges, frequently expressed in a willfully obnoxious and
unnecessarily truculent way that makes you hope you never have the
misfortune to share a beer with them (the initials "D.U." spring to
mind here)
> --
> Eric.Sos...@sun.com
Malcolm McLean
> [comp.lang.c] Malcolm McLean <regn...@btinternet.com> wrote:
> I rather doubt that there is a significant positive correlation
> between a question having a "yes-no" answer and it being "defective".
>
manner, and the question being defective.
CBFalconer
Yes, it is -5, in the modulo arithmetic used for unsigned objects.
This happens to be identical to MAX_SIZE_T - 4. You probably don't
know what MAX_SIZE_T is on your system, and can't find out
directly. However, the value exists.
--
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
CBFalconer
>
... snip ...
>
> This compiles under lcc-win32:
> void _stdcall fn(void)
> {
> int _stdcall=0;
> }
Which, I believe, proves that lcc-win32 is not a C compiler. That
'code' is purposeless, does nothing, and should produce some sort
of reaction in any compiler.
jacob navia
> jacob navia wrote:
> ... snip ...
>> This compiles under lcc-win32:
>> void _stdcall fn(void)
>> {
>> int _stdcall=0;
>> }
>
> Which, I believe, proves that lcc-win32 is not a C compiler. That
> 'code' is purposeless, does nothing, and should produce some sort
> of reaction in any compiler.
>
Hi Chuck!
As it seems, you didn't take your much needed holidays... That was
a bad decisions: you are irascible and tend to spew a lot of
nonsense :-)
The purpose of that code was to prove that the identifier _stdcall is
recognized only at file scope. It is not recognized as special
in an inner scope as required by the standard. _stdcall starts with a
single underscore and it is not reserved at an inner scope, as
Eric Sossman had pointed out.
jacob
Keith Thompson
> jacob navia wrote:
>>
> ... snip ...
>>
>> This compiles under lcc-win32:
>> void _stdcall fn(void)
>> {
>> int _stdcall=0;
>> }
>
> Which, I believe, proves that lcc-win32 is not a C compiler. That
> 'code' is purposeless, does nothing, and should produce some sort
> of reaction in any compiler.
Allowing '_stdcall' to appear within a function declaration is within
the range of extensions explicitly allowed by the C standard. See C99
4p6:
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.
Its purpose is to demonstrate how lcc-win32 handles this particular
extension. Depending on what '_stdcall' means, it probably defines a
function that does nothing; of course, defining a function that does
nothing when called is perfectly valid. The standard does not require
a diagnostic, as long as '_stdcall' is a documented extension (if it
isn't, the compiler must report a syntax error).
IMHO a compiler that provides extensions should have a mode in which
any use of such extensions is diagnosed, but the standard doesn't
require this.
There may well be reasons why lcc-win32 is not a conforming C
compiler, but this isn't one of them.
pete
>
> Kelsey Bjarnason wrote:
> > On Sat, 25 Aug 2007 11:58:44 +0100, Malcolm McLean wrote:
> >
> >> 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,
> >
> > Size_t is, last I checked, an unsigned integer type. This would
> > be most improper for anything involving negative values:
> >
> > size_t x = -2;
> > size_t y = -3;
> >
> > What's the result of x + y? Is it -5? Not here it ain't.
>
> Yes, it is -5, in the modulo arithmetic used for unsigned objects.
> This happens to be identical to MAX_SIZE_T - 4. You probably don't
> know what MAX_SIZE_T is on your system, and can't find out
> directly. However, the value exists.
In C89 you use ((size_t)-1) instead of SIZE_MAX.
--
pete
Malcolm McLean
"Eric Sosman" <Eric....@sun.com> wrote in message
news:1188249926.607250@news1nwk...
> From the first I thought he might be a troll, but amid
> all the foolishness there was what seemed to be an actual
> frustration with the "restrictions" imposed by the Standard.
> But now I'm starting to think I should have sent the Three
> Billy Goats Gruff in his direction.
>
C". Since of course his compiler did provide a function that did just that,
he felt the advice was unhelpful.
ANSI C doesn't provide any libraries for even minimal interaction with the
console, only streams, as all regs know. Sometimes they maybe forget that
this can be surprise to newbies.
Richard Heathfield
>
> "Eric Sosman" <Eric....@sun.com> wrote in message
> news:1188249926.607250@news1nwk...
>> From the first I thought he might be a troll, but amid
>> all the foolishness there was what seemed to be an actual
>> frustration with the "restrictions" imposed by the Standard.
>> But now I'm starting to think I should have sent the Three
>> Billy Goats Gruff in his direction.
>>
> The complaint was that he was told "you can't read the keyboard in
> standard C". Since of course his compiler did provide a function that
> did just that, he felt the advice was unhelpful.
I have kept out of this thread up until now, for what I hope are obvious
reasons. But it appears that some people participating in this thread
are unaware of the background.
It all goes back to 23rd November 2002, in a thread entitled "help", in
which the OP gave some very bad advice, that I (among others)
corrected. The OP took exception to being corrected, and launched a
long series of vituperative rejoinders, notable more for their heat
than for their light.
In one of them, he threatened to break my nose. (No, really he did.)
He also wrote a negative and indeed expletive review of "C Unleashed"
which he then posted on Amazon (and the review made it very clear that
he has not actually read the book).
In December 2002, he posted a thread to - I think - comp.std.c and
comp.lang.c.moderated, entitled "Richard HeathField. Bad ideas!", from
which the OP in this thread is derived.
On that occasion as on this, I stayed well out of it and he was put
firmly in his place by a number of C experts.
Al Balmer
<r...@see.sig.invalid> wrote:
>Malcolm McLean said:
>
>>
>> "Eric Sosman" <Eric....@sun.com> wrote in message
>> news:1188249926.607250@news1nwk...
>>> From the first I thought he might be a troll, but amid
>>> all the foolishness there was what seemed to be an actual
>>> frustration with the "restrictions" imposed by the Standard.
>>> But now I'm starting to think I should have sent the Three
>>> Billy Goats Gruff in his direction.
>>>
>> The complaint was that he was told "you can't read the keyboard in
>> standard C". Since of course his compiler did provide a function that
>> did just that, he felt the advice was unhelpful.
>
>I have kept out of this thread up until now, for what I hope are obvious
>reasons. But it appears that some people participating in this thread
>are unaware of the background.
>
>It all goes back to 23rd November 2002, in a thread entitled "help", in
>which the OP gave some very bad advice, that I (among others)
>corrected. The OP took exception to being corrected, and launched a
>long series of vituperative rejoinders, notable more for their heat
>than for their light.
Interesting. It appears that his current post was constructed from
bits and pieces of the "Bad ideas" thread, no new material. In light
of the posts by some (not you) about complaints made to his ISP, I
also found his news server's description of itself interesting:
"This site is designed as a last resort access way to USENET for those
who can't find a better option"
>
>In one of them, he threatened to break my nose. (No, really he did.)
Not just the nose <g>:
" But it quite obviously you need it smashed up u asshole. Maybe some
other parts of you too."
>
>He also wrote a negative and indeed expletive review of "C Unleashed"
>which he then posted on Amazon (and the review made it very clear that
>he has not actually read the book).
>
>In December 2002, he posted a thread to - I think - comp.std.c and
>comp.lang.c.moderated, entitled "Richard HeathField. Bad ideas!", from
>which the OP in this thread is derived.
>
>On that occasion as on this, I stayed well out of it and he was put
>firmly in his place by a number of C experts.
--
Al Balmer
Sun City, AZ
Paul
Richard HeathField in 2002. I only found out about this history from Mr
HeathField's post quoted below. I would never threaten anyone and any
violence makes me sick in the stomach.
What happened was I have real frustrations about the negative way people
in this forum use the standard to restrict what people can do with C,
and I searched Google to find if it had been discussed already. I found
the "HeathField Bad Ideas" post, I thought that it reflected my views in
a nutshell and basically plagiarized it.
I'm sorry if this has brought up bad memories for Mr HeathField - I
really didn't realize it had that extra dimension.
Malcolm McLean
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
news:f7-dnV-7Gqg...@bt.com...
> Malcolm McLean said:
>
>> The complaint was that he was told "you can't read the keyboard in
>> standard C". Since of course his compiler did provide a function that
>> did just that, he felt the advice was unhelpful.
>
> I have kept out of this thread up until now, for what I hope are obvious
> reasons. But it appears that some people participating in this thread
> are unaware of the background.
>
> It all goes back to 23rd November 2002, in a thread entitled "help", in
> which the OP gave some very bad advice, that I (among others)
> corrected. The OP took exception to being corrected, and launched a
> long series of vituperative rejoinders, notable more for their heat
> than for their light.
>
> In one of them, he threatened to break my nose. (No, really he did.)
>
> He also wrote a negative and indeed expletive review of "C Unleashed"
> which he then posted on Amazon (and the review made it very clear that
> he has not actually read the book).
>
> In December 2002, he posted a thread to - I think - comp.std.c and
> comp.lang.c.moderated, entitled "Richard HeathField. Bad ideas!", from
> which the OP in this thread is derived.
>
> On that occasion as on this, I stayed well out of it and he was put
> firmly in his place by a number of C experts.
>
Five years is rather a long time to nurse a resentment. Some people don't
have much of a life, I expect.
The 2007 post itself was rather arrogant and ill-tempered, but didn't
contain any bad language or threats of violence, so I rather misread the
situation.
Charlton Wilbur
P> What happened was I have real frustrations about the negative
P> way people in this forum use the standard to restrict what
P> people can do with C,
Nobody here is doing that. Do whatever the hell you want with C.
Just don't talk about it here, if it's not standard portable C.
In other words, what we say, frequently, is that this newsgroup is for
discussion of standard C, and that things which are not standard C,
which is to say things which are not described by any version of the C
standard, should be discussed elsewhere, and answers given here should
refer only to standard C, though suggestions of system-specific things
to look at and redirections elsewhere are not usually frowned upon.
I would wager that just about every knowledgeable regular in this
newsgroup uses non-standard bits of C on a near-daily basis. The
principal difference is that if we want to talk about the parts of C
we use that aren't covered by the standard, we don't do it here: we do
it in comp.unix.programmer, or Apple's carbon-dev mailing list, or
some microsoft.* newsgroup.
Attacking Mr Heathfield (*not* Mr HeathField, as you would see if you
paid attention to the way he spells his name) because you don't like
that what you want to talk about is considered off-topic in this
newsgroup is like yelling at the lifeguard because the sea is salty
when there's a swimming pool 50 yards away. It does little to change
the situation, and makes you look like an ignorant, abrasive boor.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Ian Collins
>
> What happened was I have real frustrations about the negative way people
> in this forum use the standard to restrict what people can do with C,
> and I searched Google to find if it had been discussed already.
If you are still reading this thread, why have you failed to respond to
the initial requests for examples and clarification? Otherwise, you
simply appear as a troll.
--
Ian Collins.
Default User
> I want to say that I am not the person
Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>
Keith Thompson
> I want to say that I am not the person involved in any threats with
> Richard HeathField in 2002. I only found out about this history from Mr
> HeathField's post quoted below. I would never threaten anyone and any
> violence makes me sick in the stomach.
>
> What happened was I have real frustrations about the negative way people
> in this forum use the standard to restrict what people can do with C,
> and I searched Google to find if it had been discussed already. I found
> the "HeathField Bad Ideas" post, I thought that it reflected my views in
> a nutshell and basically plagiarized it.
>
> I'm sorry if this has brought up bad memories for Mr HeathField - I
> really didn't realize it had that extra dimension.
The 2002 poster used the name "Paul", with an e-mail address of
<paulcr<nospambots>@noplacespecial.fsworld.co.uk>. You call yourself
"Paul" with an e-mail address of <pau...@mial.com>. So you didn't
just plagiarize the 2002 article, you posted under the same name.
I don't know (or care) whether you're lying about not being the 2002
poster. Either way, you've made a complete fool of yourself. I
suggest you go away and never return. Please don't bother explaining
yourself, just go away. You've done enough.
Malcolm McLean
> I don't know (or care) whether you're lying about not being the 2002
> poster. Either way, you've made a complete fool of yourself. I
> suggest you go away and never return. Please don't bother explaining
> yourself, just go away. You've done enough.
>
Fair enough. I don't mind people saying nasty things about Richard's
programming abilities, but there are limits to what the group should
tolerate. That needed to be clarified.
Al Balmer
wrote:
>I want to say that I am not the person involved in any threats with
>Richard HeathField in 2002. I only found out about this history from Mr
>HeathField's post quoted below. I would never threaten anyone and any
>violence makes me sick in the stomach.
>
>What happened was I have real frustrations about the negative way people
>in this forum use the standard to restrict what people can do with C,
>and I searched Google to find if it had been discussed already. I found
>the "HeathField Bad Ideas" post, I thought that it reflected my views in
>a nutshell and basically plagiarized it.
>
You plagiarized the name of the author, as well? And didn't expect
that anyone would think you were the same person? Pardon my
skepticism.
BTW, don't top-post.
Keith Thompson
Of *course* he's a troll. He admits to having plagiarized a
5-year-old article.
Paul
it's useless to argue here - the consensus is obviously that C is an
academic language that exists in theory but can never be used in
practice, at least not if you want to do something as basic as seeing
whether a key was pressed. I'll stick with reading books.
Apologies again to anyone I unwittingly upset by bringing back memories
of threats against someone here.
Keith Thompson
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnps171...@nuthaus.mib.org...
>> I don't know (or care) whether you're lying about not being the 2002
>> poster. Either way, you've made a complete fool of yourself. I
>> suggest you go away and never return. Please don't bother explaining
>> yourself, just go away. You've done enough.
>>
> He says he wasn't the same person who threatened to break Richard's
> nose. Fair enough. I don't mind people saying nasty things about
> Richard's programming abilities, but there are limits to what the
> group should tolerate. That needed to be clarified.
Either he's a troll who threatened to break Richard's nose, or he's a
troll who didn't threaten to break Richard's nose. The reaction of
the group should, IMO, be the same in either case. (Richard is
entitled to respond to the threat if he so chooses, but it took place
5 years ago.)
Al Balmer
wrote:
(Top-posting, again.)
>I didn't see any request like that.
Then you didn't actually read the replies. There were several such
requests.
> Anyway I've come to the conclusion
>it's useless to argue here - the consensus is obviously that C is an
>academic language that exists in theory but can never be used in
>practice, at least not if you want to do something as basic as seeing
>whether a key was pressed. I'll stick with reading books.
>
I find it quite amusing that you wrote:
"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."
while just today, I was reading a post by Richard Heathfield advising
someone on the use on conio.h, kbhit(), and getch(), as well as the
Windows APIs for character I/O.
Of course, that post was in an appropriate newsgroup, not in
comp.lang.c.
Ian Collins
Top post corrected.
>
>
> On 28 Aug 2007 at 19:32, Ian Collins wrote:
>> Paul wrote:
>>> What happened was I have real frustrations about the negative way people
>>> in this forum use the standard to restrict what people can do with C,
>>> and I searched Google to find if it had been discussed already.
>> If you are still reading this thread, why have you failed to respond to
>> the initial requests for examples and clarification? Otherwise, you
>> simply appear as a troll.
>>
> I didn't see any request like that. A good troll puts up a fight when
cornered.
Then you obviously didn't read any of the replies, for example I asked:
> 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.
> Anyway I've come to the conclusion
> it's useless to argue here - the consensus is obviously that C is an
> academic language that exists in theory but can never be used in
> practice, at least not if you want to do something as basic as seeing
> whether a key was pressed. I'll stick with reading books.
>
Every system (which is quite a few) I use with a keypad has a different
method for input. I work on several that don't have one.
All of them are 90% standard C.
--
Ian Collins.
Richard Heathfield
<snip>
> Either he's a troll who threatened to break Richard's nose, or he's a
> troll who didn't threaten to break Richard's nose. The reaction of
> the group should, IMO, be the same in either case. (Richard is
> entitled to respond to the threat if he so chooses, but it took place
> 5 years ago.)
My response five years ago was not to bother to respond. The guy is
clearly in need of medication, and I'm not a doctor, so what can I do?
user923005
> Keith Thompson said:
>
> <snip>
>
> > Either he's a troll who threatened to break Richard's nose, or he's a
> > troll who didn't threaten to break Richard's nose. The reaction of
> > the group should, IMO, be the same in either case. (Richard is
> > entitled to respond to the threat if he so chooses, but it took place
> > 5 years ago.)
>
> My response five years ago was not to bother to respond. The guy is
> clearly in need of medication, and I'm not a doctor, so what can I do?
It's hard to feel sorry for net trolls like Nudds, Plutonium, Harris,
etc. but really they are in serious need of help.
Considering the history of USENET, I guess that they almost never get
it.
Ben Bacarisse
> I want to say that I am not the person involved in any threats with
> Richard HeathField in 2002. I only found out about this history from Mr
> HeathField's post quoted below. I would never threaten anyone and any
> violence makes me sick in the stomach.
>
> What happened was I have real frustrations about the negative way people
> in this forum use the standard to restrict what people can do with C,
> and I searched Google to find if it had been discussed already. I found
> the "HeathField Bad Ideas" post, I thought that it reflected my views in
> a nutshell and basically plagiarized it.
OK, just so that we know what form this "plagiarism" took, here is
your message that started this thread marked so:
| Message-ID: <slrnfcuibh....@nospam.invalid>
| Date: Fri, 24 Aug 2007 23:11:27 +0200 (CEST)
interleaved with the message from the "other" paulcr marked so:
: Message-ID: <as9jj5$bhi$2...@news5.svr.pol.co.uk>
: From: "Paul" <paulcr<nospambots>@noplacespecial.fsworld.co.uk>
: Date: Sat, 30 Nov 2002 05:45:18 -0000
| 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.
: This guy 'Richard Heathfield' however 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.
: 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?
: 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?
: 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'?
: 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'?
I would argue some of these points with you, but you are either the
same paulcr, and now want to distance yourself from that last row, or
you deliberately posted someone else's inflammatory text. Neither
suggests that debate is likely to be worthwhile.
--
Ben.
Kenneth Brody
[...]
> The Standard says that strchr() and its friends are
> declared in <string.h>. It does not forbid an implementation
> from providing a <strings.h> header in addition, but it saves
> the programmer from having to write
>
> #if defined(PLATFORM_X) || defined(PLATFORM_Y)
> #include <strings.h>
> #else
> #include <string.h>
> #endif
>
> Yes, we had to do this -- and worse -- in the Bad Old Days.
> Now, we don't need to.
[...]
No need to remind me. I remember the "fun" in writing a varadic
function in pre-ANSI days. (Or should I say "multiple versions of
the module containing the varadic function, in order to support
the multiple variations in header files, macros, and so on"?) In
fact, they're still there, #if'ed out, for the rare non-ANSI
compilers we support. (Yes, the default HP-UX compiler is
non-ANSI. It even goes so far as to recognize, yet fail to
compile, prototypes, stating that you need the ANSI version of
the compiler to do so. At least that's what it did a few years
ago when I last used one.)
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsA...@gmail.com>
Kenneth Brody
>
> Michal Nazarewicz <min...@tlen.pl> writes:
> > 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?
> >
> > a routine to access keyboard in given implementation. Standard only
> > specifies the minimal requirements implementation have to fulfil.
> [...]
>
> Yes, the standard does restrict the language in many ways. For
> example, an implementation can't yield the value 5 for the expression
> 2+2.
That's not a "restriction", it's a "requirement". It requires that
that the implementation properly implement "+" when no overflow
occurs.
pete
>
> Malcolm McLean said:
>
> >
> > "Eric Sosman" <Eric....@sun.com> wrote in message
> > news:1188249926.607250@news1nwk...
> >> From the first I thought he might be a troll, but amid
> >> all the foolishness there was what seemed to be an actual
> >> frustration with the "restrictions" imposed by the Standard.
> >> But now I'm starting to think I should have sent the Three
> >> Billy Goats Gruff in his direction.
> >>
> > The complaint was that he was told "you can't read the keyboard in
> > standard C".
> > Since of course his compiler did provide a function that
> > did just that, he felt the advice was unhelpful.
>
> I have kept out of this thread up until now,
> for what I hope are obvious
> reasons. But it appears that some people participating in this thread
> are unaware of the background.
> It all goes back to 23rd November 2002,
> in a thread entitled "help", in
> which the OP gave some very bad advice, that I (among others)
> corrected. The OP took exception to being corrected, and launched a
> long series of vituperative rejoinders, notable more for their heat
> than for their light.
I found a different thread very much like that one:
http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/b76ec067270d9cf6
> In one of them, he threatened to break my nose.
> (No, really he did.)
I found that one.
http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/82c5c4b2e59984e0
> In December 2002, he posted a thread to - I think - comp.std.c and
> comp.lang.c.moderated, entitled "Richard HeathField. Bad ideas!", from
> which the OP in this thread is derived.
I found that one.
He just copied that one without the first two paragraphs,
to make the original post in this thread now here in clc.
http://groups.google.com/group/comp.lang.c.moderated/msg/e92069ef14401443
> On that occasion as on this, I stayed well out of it and he was put
> firmly in his place by a number of C experts.
He is a very powerful troll.
Much stronger than our resident ones.
This is my fourth post in his thread.
--
pete
Dik T. Winter
> I didn't see any request like that. Anyway I've come to the conclusion
> it's useless to argue here - the consensus is obviously that C is an
> academic language that exists in theory but can never be used in
> practice, at least not if you want to do something as basic as seeing
> whether a key was pressed. I'll stick with reading books.
Apparently you are clueless. I have now four windows open on this system.
On all four windows I talk to a C application. Within *none* of the
windows it is possible to find out whether a key is pressed or not.
The *only* connection between the keyboard and the other ends are
character streams.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Chris Hills
<cwi...@chromatico.net> writes
>>>>>> "P" == Paul <pau...@mial.com> writes:
>
> P> What happened was I have real frustrations about the negative
> P> way people in this forum use the standard to restrict what
> P> people can do with C,
>
>Nobody here is doing that. Do whatever the hell you want with C.
>Just don't talk about it here, if it's not standard portable C.
I think you have just proved his point.
>In other words, what we say, frequently, is that this newsgroup is for
>discussion of standard C,
That is for comp.std.c This group is for the use of C.
The "standard C" the pedants here refer to seems to encompass ANY
version of C including unpublished drafts but not the real world use of
C.
This is a mistake. Instead of screaming "that is non-standard go away"
we should have a slightly more relaxed view. Yes point people at more
appropriate groups but don't be holier than thou about it and some
discussion of C that is not pure ISO C is nto a bad thing.
We will not get swamped in "OT" posts. What i happening at the moment is
that we are getting swamped in posts shouting OT and the subsequent
argument,
If all those who yell "OT!" every 5 minutes refrained from doing so I
think we would have a far better group and the signal to noise ratio
would drop because we would not have then constant "is it OT" argument
raging.
It would also expand the cause of using portable c (where appropriate)
at the moment most who drop in and ask an "OT" question usually leave
very quickly thinking that the group is full of a pedant net nannines
who are not connected to the real world. That helps no one.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/