portability

[Doug Gwyn]

In article <349 at sdti.SDTI.COM> turner at sdti.UUCP (0006-Prescott K. Turner, Jr.) writes:
>X3J3 did the best they could.

I hope you meant X3J11.  X3J3 is Fortran, I think.

>However, the ANSI definition of WORKING will certainly differ on
>occasion from what users expect.

That depends on whether users get their ideas from bogus sources
or not.

>In particular, the standard does not require that when an object is
>declared volatile, every access to it will be an atomic operation
>uninterrupted by other processes.

Of course not.  Only sig_atomic_t has any requirement of atomicity.
Most implementations would have to haul in a large amount of
semaphore baggage in order to guarantee atomicity for general types.
That wasn't the purpose of the "volatile" type qualifier; avoiding
excessive optimization was its purpose.

The proposed C Standard deliberately avoids attempting to deal with
concurrent process issues.  There might be some point in a future
Standard dealing with this, but it was felt to be premature to
settle how it should be done at this time.

>A good C compiler will make such operations atomic when the hardware
>has efficient support for it.

No argument there.  If a program DEPENDS on the volatility of an
object for its correct operation, it is inherently non-portable
and consequently needs to be tweaked for the specific behavior
of its compilation and run-time environment.  The "volatile"
type qualifier merely makes it feasible for such environments to
employ a higher degree of optimization in non-volatile cases than
would otherwise be possible, because there is an escape available
when it's necessary.