const, volatile, etc [was Re: #defines with parameters]
Ray Dunn
ray at micomvax.UUCP
Thu Dec 8 10:12:43 AEST 1988
In article <10919 at ulysses.homer.nj.att.com> ggs at ulysses.homer.nj.att.com (Griff Smith) writes:
>....
>I agree, and I don't object, but some brief encounters with an ANSI
>compiler make me worry about it a bit. The problem is that the
>existence of the volatile qualifier makes it possible to do
>optimizations that were previously forbidden (or at least difficult to
>slip past the customers). I blew several hours discovering that a flag
>set by a signal handler had been optimized out of existence because it
>wasn't declared volatile.
There is the implication here that the introduction of the "volatile"
qualifier is the *cause* of the problem.
This is of course not true, the qualifier is an attempt to provide a
*solution* to the problem.
Many existing pre-ANSI compilers will optimize away memory references that
are in fact required because the variable is "volatile" but the compiler has
no way of knowing.
In pre-ANSI 'C', *all* variables are regarded as being *non-volatile*, the
compiler is free for example to keep the variable in a register, and there
is usually no way to selectively stop the compiler optimizing their
references away.
You usually can turn off optimizations globally while compiling a module.
One technique to use is to collect all fucntions containing volatile stuff
into one or more modules, and only compile *them* with optimisation off.
The "volatile" qualifier is a *much* better solution when you have an ANSI
Conforming compiler.
--
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
More information about the Comp.lang.c
mailing list