[Info-vax] yet another sys$qiow question

[David Froble]

Bob Gezelter wrote:
> On Saturday, August 22, 2015 at 12:29:06 AM UTC-4, JF Mezei wrote:
>> I think I understand the volatile issue.
>>
>> However, since the IOSB is a structure, pedandically speaking, wouldn't
>> the compiler treat each member of the structure independantly ?
>>
>> aka: reading the first member repeatedly might cause it to be optimized
>> to register (or optimized away), but even if it has happened, reading
>> the second member of structure would cause a memory fetch of the second
>> value.   Right ?
>>
>>
>> What about character buffers ?
>>
>> Say I put 0x00 as first byte of a 250 byte char buffer. Call QIO to read
>> data into buffer, and then loop until the first byte of buffer is no
>> longer 0 (I know, even worse practice than looing to check IOSB :-)
>>
>>
>> Would the compiler also optimize this loop away, even if it is character
>> data ?
>>
>> From a programmer's point of view, if I were to test for
>> strlen(buffer) != 0
>>
>> How do I know as a programmer whether "strlen" will be considered an
>> external routine (which will impart "volatile" on buffer), or  a known
>> routine which the compiler will inline code, and then optimize because
>> it knows that strlen won't modify buffer so the whole thing can be
>> optimized away ?
>>
>> If I declare buffr as "volatile", it is correct to state that I no
>> longer have to worry about whether a routine is external or inline code
>> since buffer will always be assumed it could change ?
> 
> JF,
> 
> Looking at the contents of a buffer BEFORE completion is not simply "a worse"
> practice. It is out-and-out wrong.

Ayep ...

> From the time that an IO operation is initiated (e.g., QIO call), till the
> time of IO Post processing, which updates the IOSB, sets the event flag, and
> queues (not invokes) the AST (ASTs are queued FIFO by access mode within a
> process), the contents of a buffer are UNDEFINED.
> 
> UNDEFINED means UNDEFINED. There are (literally) NO LIMITS on what a driver
> may do with a buffer. There are no requirements of consistency between
> related devices (e.g., TTDRV, LATDRIVER, TNADRIVER). The contents of the
> buffer may be zeroed, may contain junk, may be filled in any order convenient
> to the driver (e.g. consider the cases of magtape Read Reverse).
> 
> A more dangerous problem is an IOSB or buffer going out of scope. If a buffer
> or IOSB is allocated on the stack, and the routine returns before the
> operation completes, the stack can get arbitrarily corrupted, with the
> unpredictable results.
> 
> - Bob Gezelter, http://www.rlgsc.com

If you're going to exit a routine that queued up a QIO, or other async service, 
before the operation is complete, then don't cha think that cancelling the thing 
might be the thing to do?  If I remember correctly, and no, I haven't done much 
of this, the AST would then never be queued.  Nor should it.

If I remember correctly,