File: PA:[22,310]PA3MEMO.TXT     Last edit: 17-JUL-1989 12:03:57 

We have recently encounter an obscure bug and I am not yet sure how
to cleanly resolve it.  In fact, we may not be able to.  

In particular, we had the following code:

par_list[1]:= loophole(word,ref(buffer));  {address of input buffer}
par_list[2]:= 5; { length of input buffer}
par_list[3]:= 1; { 10 sec timeout }
par_list[4]:= 0;
par_list[5]:= 0;
par_list[6]:= 0;
buffer[1]:= chr(65);
Qiow(IO_RLB+TF_TMO,Chart_lun,f1,IOstat,Par_list);
{ entry was ZZZZZ }
if buffer[1] = 'Z' then exit else writeln('input value is "',buffer[1],'"');
writeln('full input value is "',buffer,'"');


The program read in the fize character ZZZZZ string, but did not exit.
Instead it informed us that the value of BUFFER[1] was "A", and
then that the value of BUFFER was "ZZZZZ".

Examination of the macro code showed that the root of the problem was
the compiler optimization.  Since BUFFER[1] had just been initialized,
and its value was retained in a register, that same value was reused
in the WRITELN statement, since the compiler knew that the value had
not changed.  This was not the case as the QIOW call had indeed affected
the value of BUFFER.

This was confirmed by making BUFFER a global variable (BUFFER[1] could
now be hardcoded, and no further optimization was possible).  I did not
check, but I am sure that if the QIOW subroutine had referenced BUFFER
as a VAR parameter, it would have also not reused the value of BUFFER[1].

When using LOOPHOLE or REF, we can create situations where we hide
the actual variable we are working with from the compiler.  We may get in
trouble if we are working with this variable in a byte or word form.

The workaround is to make global any variable that will be modified by a 
routine that references that variable using an address that was
created indirectly by LOOPHOLE or REF.

In particular, the following P3UTIL routines will modify variables that
are passed as addresses: QIO, QIOW, and VRCD.  The receive message packet
routines (RCVMSG or SRECV) use VRCD, however, they should be okay
as their parameters directly reference the variables affected.

For now, we will leave things as is, keeping in mind this potential
problem.  Jim, if you have any thoughts, let me know.  Bob has created
a program that produces the problem with a minimum of code.