const, volatile, etc [was Re: #defines with parameters]

[Guy Harris]

>It seems that my problem with Doug Gwin is that he cannot conceive that his
>rationales can be doubted: if you want signed characters, the only way is
>to add a signed keyword, if you want efficient code the only way is a complex
>optimizer that relies on volatile.

Err, umm, first of all, that's "Gwyn", not "Gwin", as you can check the
attribution line in your posting.

Second of all, you appear also not to conceive that the notion that C is
a language whose compilers shouldn't optimize can be doubted, either. 

To put it bluntly, that's rubbish.  There are plenty of people out there
who can, I suspect, testify that yes, indeed, optimizing C compilers
*can* produce better code than non-optimizing ones, *even when the C
source is, in some sense, "good" code.*

As such, statements such as:

>You mean that nobody explicitly stated the obvious rule that an optimizer
>shall not turn a correct program into in incorrect one? Of course! As I said,
>C was not designed for optimizing compilers; it was designed as a low level
>language, and the very idea that an optimizer could do nasty things behind
>the programmer's back was unthinkable.

are unlikely to be very convincing to a large (and, I suspect
increasing) portion of the audience.  Sorry, but the notion that "the
very idea that an optimizer could do nasty things behind the
programmer's back was unthinkable" isn't as widely accepted as you
appear to wish it to be - and, I suspect, never was - and just because
some people *assumed* that the compiler generated "straightforward" code
doesn't mean 1) it was true in most implementations or 2) it was to be
taken in any way to be a guarantee. 

By and large, your arguments on "volatile", etc.  amount to "C was
always supposed to be a language whose compilers did little
optimization, and C compilers shouldn't do lots of optimization,
period."  Merely stating this premise repeatedly isn't going to convince
a lot of us, because we've seen quite good C code turned into better
code with a high-power optimizer on than with it off (and no, simply
declaring that that code must therefore not have been very good isn't
going to convince us, either).  Please try another approach, preferably
one involving hard data showing that good *and* readable C code
*doesn't* get turned into significantly better code when run through a
compiler with a more powerful optimizer than when run through a more
"straightforward" compiler - and showing this in a reasonable range of
modern architectures, including (but not limited to!) modern RISC
architectures.  "Proof by blatant assertion" isn't good enough.