Re: The annotated annotated annotated C standard

Have you ever wondered why things are "less well understood" as
opposed to being crystal clear? Part of your responsibility was making
things easy to explain but with multi-byte characters and sequence
points you managed to make things impossible for even their creators,
you among them, to explain them.

No it is not. Standards are the same thing as reference books.
All that is required is standards are consistent and interpretion is
unambiguous.
Failure on these points warrant Defect Reports (and these have been
submitted on the current standards)
Sometimes the Defect Reports are accepted, sometimes rejected (with notes as
to why is correct).
But there is no fundamental requirement for the standards to be less opaque
and easy to read.
They are not primarily there to educate the masses on C or C++.
They are not Janet-and-John or ***-and-Jane books.

Let's stop pussyfooting around. Most competent females have left the
field because like Julienne here they are offended at the way boys
(not men) in recent years have made it their job as so-called
programmers to destroy people and not actually program. So drop the
gender affectation.

Furthermore, your example is based on a the lower middle class urban
legend that the only kind of programming labor there is, is solo new
development, whereas in C this is most assuredly not the case.

All of this tells me that you _KNOW_ you have lost the argument,
you _KNOW_ you are never going to win on technical grounds,
so you are _REDUCED_ to finding small non-technical points and
mounting attacks on them.

Does anyone in comp.progamming care for your subjective nonsense on "lower
middle class urban legends"?
Or does anyone in comp.progamming care for your diversionary words on "Most
competent females have left the field "?
None of them are about your original subject matter "The annotated annotated
annotated C standard"

Although Herb belonged on the standards team, and not you, because he
is more willing to communicate clearly and not obfuscate, he wasn't
parroting the standard or trying to make you look good. Instead he was
trying to explain your mess to the vast majority of real programmers.

Your standard isn't Holy Writ.

Ah but it is. The original authors

It is instead a report on the doomed
effort to make a silk purse out of a sow's ear so that corporations
could still make money by vending C compilers, stamped USDA prime in a
deceptive fashion, since to make C appropriate for any new development
of any sort, you'd have to throw it out and start over. No programming
language without textual static nesting of "functions" or preferably
classes to n levels is worth using. The only reason why C Sharp is
viable is that although its functions cannot be nested (a function
cannot be defined in a function) classes and other structures can be,
relegating the function to a detail.

Therefore, you were asking Herb to mindlessly repeat your nonsense. He
made the brave choice not to do so, and not to give you a respect you
did not earn.

But you dont know that. Unless your Herb you have _NO IDEA_ as to his
motives.
It is PURE CONJECTURE on YOUR part.

Although this is NOT an "error" at all, the purpose being to ruin
Schildt's reputation

A comment two messages ago by you but agian
PURE CONJECTURE on YOUR part.

The Standard requires
rather fewer error messages than people expect. At the time I was

Oh, the Standard requires rather fewer error messages than mere
mortals expect? And this is an advance?

No it is left to the implemention. Both C and C++ standards talk about
"diagnostics" and that it it.
The standards are silent about "quality of implementation" matters.
It is not the jurisdiction of the standard to talk about compiler switches,
warnings, implementation details.

He's not my hero. Most people in programming repel me. However, I am
repelled even more when computer science is distorted into a
personality competition. I really just don't care about this main()
issue because it is marginal. At least his error concerning block
scope is important, and you should have focused on this.

It is not marginal. I have pointed above one place above where ignoring this
can get you in trouble.
Is it the case, that Nilges supports technical books with incorrect content
and any attempt to draw attention to that is entering into a personality
competition?

You and your buddies defined a number of situations as "undefined" and
yet at the same time took the position that C need not produce many
error messages.

It is not the case of "You and your buddies".
Most of the places where C (and C++ for that matter) standards calls
something "undefined" is because the hardware (or OS) may do some
unexpected. Like terminate your program.
For example "dividing by 0" is undefined. free()'ing the same pointer twice
is undefined.
The standards "undefined" is equivalent to posting a notice on a pond frozen
with ice, "THIN ICE".
As long as programmers take care to never allow their programs to skate in
that area, their progams will behave well.
If you decide to skate over the "THIN ICE", there is no guarantee what will
happen to your program.

Stephen Howe


.