[Info-vax] yet another sys$qiow question

[Craig A. Berry]

On 8/21/15 1:07 PM, Stephen Hoffman wrote:
> On 2015-08-21 16:26:04 +0000, Craig A. Berry said:
>

>> The only thing the discussion of volatile has added is yet another
>> reason not to do it that way [polling IOSB].
>
> Unfortunately and AFAICT, omitting volatile for any of the completion
> paths means that any of the IOSB paths can potentially pick up a bogus
> value.  That seems very unlikely, but it is permissible behavior for the
> compilers.

According to the C standard, everything is effectively volatile when it
crosses from one "translation unit" to another, i.e., not in the same
pre-processed source file.[1] As long as SYS$SYNCH is a real routine and
not a macro or inlined function, it's always going to be in a different
translation unit from user code, so when passing the IOSB by reference
to SYS$SYNCH, it would be redundant to make it volatile.

AST completion routines that check an IOSB declared as a file scope or
otherwise global struct *might* get into trouble. I'm not sure about
that case. But the more normal method would be to have the IOSB hanging
off the AST parameter, and in this case, volatile would also be
redundant because function parameters and anything they point to are
required to be interpreted according to "abstract semantics,", i.e., the
code as written, without any optimizations.

My footnotes reference the C99 standard, section 5.1.2.3 item 10. It's a
description of a possible implementation, but the only alternative
implementation described is one that performs no optimizations at all.
So I'm considering what I've quoted as an indication of what must happen
in a compiler that does any optimizations. I'm sure someone will point
it out if I've misread anything.


[1] "an implementation might perform various optimizations within each
translation unit, such that the actual semantics would agree with the
abstract semantics only when making function calls across translation
unit boundaries."


[2] "at the time of each such function entry the values of the
parameters of the called function and of all objects accessible via
pointers therein would agree with the abstract semantics."