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