Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: C Standards | Date | Thu, 21 May 1998 16:28:59 +0200 (MET DST) |
| |
:-)
> 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
| |