Re: The annotated annotated annotated C standard

On Jan 20, 6:35 am, "Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote:
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.

This was the case in out of date languages. It is no longer the case.
In fact, a runtime error produced by a bounds checker is preferable to
"undefined behavior", as is INF or a similar symbol.

In fact, mathematics itself progressed because mathematicians weren't
intimidated by thugs on standards committees, whence complex numbers.

Had the C standards committee been around at the time of Gauss, or
Euler, they probably would have conducted a *kultur kampf* against
them, and tried to enlist the Prussian police in suppressing their
dangerous innovations.

In fact, this has happened in the history of science, with the Galileo
case being Exhibit A.

The analogy is imperfact. For example, nonsense about "sequence
points" probably and as far as I can tell probably belongs with cold
fusion and the aether.

But in mathematics, as opposed to programming, division by zero has a
result in the sense that it's the limit of the function x/y as y
approaches zero, I believe. Genuine math geeks as opposed to thugs are
welcome to correct me on this matter, of course.

It's in fact perfectly sensible to converge on x==0 in a try..catch
block in a usable modern language. Insofar as C treats this as
"undefined", it's a pretty useless language.

One thing we do know is that posting tirades using caps lock about
bad, Commie programmers is signally unhelpful.

This is because, as I've pointed out to Clive, that the programmer
almost never owns the code. He's therefore responsible for coding a
canonical member of a series or class of programs which are safe to
maintain, and if he chooses C he should be let go.

In 1986 I was given the choice of C or True Basic to develop the
Onboard Stability Program for hydrostatic stability at The Glosten
Associates. I chose True Basic because although it lacks the more
modern syntax of C, it lacks its semantic randomness and its contempt
for error handling. As a result, the program was a success and was
rewritten in Visual Basic after obtaining several satisfied customers
in this rather mission-critical system.

My job wasn't to write, once and for all, the final solution. It was
to create a model and a canon for a series. The series was a success
in part because I didn't have to waste my time with C's childish
attempt to reconcile a basically adolescent approach with Algol.

Basic with the structured programming additions happens to be superior
to C. It evaluates the for limit once and doesn't allow stupid
cleverness.

I'd hazard that in most large corporations, most programmers never
even get to see the consequences of their decisions in this way, and
live instead in a sort of virtual or fantasy world in which they, and
the set of coding tics which they are pleased to call standards, are
secret geniuses whose wisdom would be recognized were it not for that
guy in the next cube who insists on being Other with respect to them.

Scraps of code, normally written under pressure, are emitted, and in
many cases these scraps do not even conform to the "standards" to
which their programmers say they adhere, the violations of good
practice being for the most part winked at or rewarded by management
for "getting a job done".

It's a wasteland.

I've known very few competent programmers in person. One was Nash. The
other was a co-worker at Bell Northern Research with psychological
problems that caused him to be extremely unpopular.

For the most part, most "programmers" don't even code that much, and
if this newsgroup is any guide, they vastly prefer joining cybernetic
mobs in order to avoid the pain of confronting their own subordinate
deprofessionalisation.



Stephen Howe

.