>On Fri, 27 Oct 1995, Dan Hollis wrote:
>
>> Ran across the following strange behavior in SPL:
>>
>>   I32               CA      I16V
>> dbineqv:=DBINARY(dasciieqv,length);
>>
>> If dbineqv is an element of a double array, the condition code of the call
>> appears to sometimes get corrupted. It never seems to happen otherwise.
>>
>> I believe this might be because SPL may be doing pointer fixup math on the
>> double array and therefore invalidating the condition code. If this is truly
>> the case, then my guess is it's possible for this to happen with any
>> intrinsic which returns an I32 (although I have not yet tested this).
>>
>> Can anyone confirm this? Is it a bug or a feature? >BD
>>
>> -Dan
>> .----------------------------------------------.
>> |Dan Hollis -- Pharmacy Computer Services, Inc.|
>> [log in to unmask]      -     (503)476-3139|
>> `----------------------------------------------'
>>
>It's been a long,longlong, long time, but I seem to recall that the
subscripting
>for the return value will affect the condition code.  The return should
>be to a simple variable, then the simple variable can be put into an
>array.
>
>NMD
>
>
 
I don't have an SPL manual here, but if I remember, this behavior is
documented in either the SPL Reference Manual or the SPL Textbook.  I seem
to remember something to the effect that since array references use the
index register, and instructions (most or all, I'm not sure which) affect
the condition code, a simple variable should always be used on the left side
of the assignment operator if the condition code will be checked (as in the
use of FOPEN, ASCII, BINARY, etc.).  If I remember on Monday, I'll see if I
can find the little "gotcha" note in the manual(s).
 
John Korb