noalias comments to X3J11

[Stan Friesen]

In article <2518 at geac.UUCP> daveb at geac.UUCP (David Collier-Brown) writes:
>
>
>In article <597 at tuvie> rcvie at tuvie.UUCP (D. Weickert) writes:
>|Signal handlers will be at least very similar to interrupt routines. Still it
>|does not seem to be esoteric to me, if I set a flag in such a handler. And now
>|please tell me, how to tell the compiler it must not `optimize' the access to
>|this flag?
>
>Well, they're interrupt-like in style, but not always in nature.  It
>is probably true that some machine and operating system somewhere on
>this net has signals which run asynchronously to the rest of the
>program, but in general they are executed in the normal context of
>a C program, as a (simulated, perhaps) subroutine call and strictly
>synchronously with the rest of the program.

	You and I seem to have a different definition of asynchronous! When I
use the term I mean that the timing of two routines in the system are
indeterminate relative to one another, *not* that only one is executing at any
given time. Yes most signal handlers are run as simulated subroutines in the
user context, BUT these pseudo-routines may be "called" at *any* time, such as
between a load and a store instruction. The programmer has no idea where the
'main' path will be executing when the handler is activated. THIS is what makes
handlers asynchronous, and what makes volatile necessary.

> And you don't, therefore have to do anything to the said flag
>variable.  Except make it accessable.

	Only if you do not use the -O flag! With optimization on the compiler
may decide that it has already loaded a value into a register and use the
cached value instead of loading fresh from the real variable. In the case
of a flag set by a signal handler this is *wrong*, since the handler may
have been called between the original load and the ultimate store. So
you do have to declare such variable'volatile', at least if you wish a
verifiably correct program.