const, volatile, etc

[Ray Dunn]

In article <10988 at ulysses.homer.nj.att.com> cjc at ulysses.homer.nj.att.com (Chris Calabrese[mav]) writes:
 >In article <1526 at micomvax.UUCP>, ray at micomvax.UUCP (Ray Dunn) writes:
 >> Nowhere is there any guarantee that each and every variable reference made
 >> in a 'C' source will translate to a memory reference in the run code.
 >> 
 >> That is what "volatile" gives you......
 >
 >#define FlameOn 1
 >This is an interesting view of this volatile issue (pun intended).
 >C (B actually)was first created to write a file system handler
 >on PDP's.  Given this fact, how could the variables _possibly_
 >been non-volatile?  Indeed, 99.9% of UNIX is written in C,
 >including _all_ the memory mapped I/O, and signal handling
 >routines which may be in the kernel......

Your argument just evaporated away (pun intended).

Maybe you didn't realize it, but unless your compiler documentation states
quite clearly that this is all safe, then you have *no* guarantee that the
code you describe *has* been compiled correctly.

The solution to this argument is really quite simple, and lies in your hands.

Unless this guarantee of non-volatility is clearly stated in one of the
bibles (K&R etc), *or* in the implementaion documentation, then you have no
justification for relying on it (and if it is specified in the latter, then
the argument still holds good for 'C' in general).

Sooo....quote chapter and verse.....

-- 
Ray Dunn.                      |   UUCP: ..!philabs!micomvax!ray
Philips Electronics Ltd.       |   TEL : (514) 744-8200   Ext: 2347
600 Dr Frederik Philips Blvd   |   FAX : (514) 744-6455
St Laurent. Quebec.  H4M 2S9   |   TLX : 05-824090