lkml.org 
[lkml]   [1998]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: C Standards
Date
:-)

> Okay, Okay. I am wrong. I am wrong. I am wrong.

That always helps to say!

> Background:
> About 8 to 10 years ago, I needed to prepare a document to support
> trying to find rules in the new C standards that could have been used
> to support such a project today. We are all lucky that C is now an

That's interesting. But it is interesting too that you made LOGICAL
errors in your assertions before, not factual ones. The confusion
between macro parentheses and function parentheses was one such
error of logic (hey? the compiler can't know about macro parentheses by
definition, because the precompielr removes them by the time the
compiler sees the output!). The error of confusing parsing precedence
with evaluation ordering was another - again these are two distinct
pahases of compilation that are always separated as much as possible
in compilers, and always have been. One is syntax, the other is
semantics.

Those two errors are logical. I can kind of understand how
memories from 10 years ago struggling up in the brain can scare one
into abandoning logic in favour of restating what one thinks one
remembers, and I'm glad you see how dangerous it is to rely on anything
other than (facts and) logic. But I still think you are blaming the
facts, not blaming the logic, for your prattfall.

> The new C standards seem mostly to be disclaimers for compiler design.

But that's fine. You can rely on what they say you can rely on, and you
can't rely on what they don't say, nor on what they say you can't rely
on. I have no problem assigning a formal semantics to such a language.
In fact, it makes programs remarkably easy to check for possible
ambiguities.

> Compilers used to be, in Dennis Richie's words, "High level
> assemblers". They used to be deterministic in their behavior.

They still are, unless they run on dual cpus and invoke unprotected
writes and reads to shared variables :-). It's the deterministic
behaviour that they choose to follow that is undefined sometimes, and
that is as it should be. It always was so. I have been writing C since
K&R times, and the situation was never any different, nor am I aware of
any significant respect in which the new rules are LESS EXACT in what
they permit and don't permit than were the old rules.

In other words, I think you are mistaking clear statements of what may
be left to implementations for being worse than obscure statements
about what implementations should do. Can we get some concrete examples
.. I am sure there are better AND worse aspects in the details, but
overall I have a better impression of the newer standards.

> What I have found in this 10 hour nightmare should scare the hell out
> of everybody that uses the C language in business.
>
> The fact that one no longer is required to de-reference pointers to
> functions, and the fact that there is no longer a "C calling

One never was as far as I know. I relied on that 10 years ago when
constructing my own compiler compiler, which worked/works by passing
pointers to functions around.

> convention", the reverse of the "Pascal calling convention", should
> bother the hell out of anybody that makes libraries.

The low level convention should be invisible. It shouldn't matter
(religious statenent, borne out by private conversations withe the
Creator of All Lanuguages). Caller unstacks or callee unstacks is a
matter of implementation. If it becomes visible it's a bad program, so
best to say explicitly not to rely on this. That's a GOOD point for the
newer standard,

> The fact that a compiler is now free to rearrange code in any way it
> wishes, should bother the hell out of anybody who writes software that
> controls machines.

It should encourage them to be careful. They can put sequence points
whenever they want. Anyway, the compiler won't make a change that can
affect the functional semantics. What you have to be careful of is
relying on NON-functional semantics, such as timing, in code.

> The fact that parentheses can be ignored by the compiler except for
> mathematics. The list goes on.

Well of course. Parentheses are for syntactic grouping. They should
never be overloaded with a semantics as well. That's a good clean
design decision.

> So I was wrong. Practically everything I learned about and defended so
> that we would not have to write software in ADA, has been decimated.
> Nice job!

And the rest of the world has known about it and indeed set it up that
way so that things would work better and be clearer, and so on. If you
find the new rules unclear in some way, please pass it on to the
standards committee ... don't they have to review every 5 years?

> Further. I was not quite aware that the C Language had become a
> religion. I always though it was a tool. Judging from both my public

The church of C! Yeah, well that's a subsect of the church of Unix.
I gave up trying to convince a student for whom Stevens apears to
occupy the status of Bible that "wait" has an abnormal semantics in
unix, in that it NORMALLY means "wait synchronously for an event", not
"wait for a process to die". I tried in vain the argument about the
little village in the mountains in which to the villagers, the word
"train" means "the big red thing with a stripe on the side that comes
and whistles at 4pm every afternoon, except saturdays".

> and private mail, I have been attacking motherhood, apple pie, and
> world-wide religious ethics. The retribution has been, well, funny!

Keep up the sense of humour!

> Richard B. Johnson
> Project Engineer
> Analogic Corporation


---------------------------------------------------------------------
Peter T. Breuer MA CASM PhD (Ing.), Prof. Asoc.
Area de Ingenieria Telematica E-mail: ptb@it.uc3m.es
Dpto. Ingenieria Tel: +34 1 624 99 53
Universidad Carlos III de Madrid Fax: +34 1 624 94 30/65
Butarque 15, Leganes/Madrid URL: http://www.it.uc3m.es/~ptb
E-28911 Spain

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.031 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site