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

[Doug Gwyn]

In article <369 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>They were not forbidden, you could do any optimization that did not impact
>the semantics of programs. A Classic C program compiled with a dpANS C
>compiler changes semantics, unless you tag with volatile all variables not
>tagged register.

This, as with practically everything else Grandi has said about C,
is simply not true.  There are a few fairly subtle changes in the
semantics going from K&R 1st Ed. C to ANSI C, for example mixed
type promotion in expressions and linkage rules, but they affect
few programs.  There was never a guarantee that C data had what is
now known as the "volatile" property.  Existing compilers in fact
give the lie to such a claim.

>Exactly the opposite!  In Classic C the concept was that the compiler would
>take register as an hint of which variables could always be safely cached in
>register (and the user be forbidden to take pointer to them), and all the
>others could be cached only if it was guaranteed that doing so would not
>"cause surprises".

Please cite references for this unique notion of what pre-ANSI C's
rules were.  So far as I have been able to determine, it was never
specified one way or another, so by the usual rules for interpreting
C rules, this would have been an unwise assumption to make.
(Particularly since existing implementations did not follow that rule.)

>Actually it is a backwards step wrt to register, as it encourages bloated
>compilers and the delusion that they can select which variables to put in
>registers better than you can do, while requiring careful analysis as to
>which variables MUST be declared volatile (as failing to tag them makes
>your program erroneous, where register is perfectly safe).

"register" is still a supported specifier under ANSI C.  Use it if
you think your compiler does a poor job of register allocation.

The use of "volatile" does not require much analysis.  If you were
paying attention, I already explained in response to Griff Smith
the cases where you need to use it.  In pre-ANSI C the same problem
existed, but there was no standard solution for it.