Re: Overlapping subfields with a MOVE

Jon Paris wrote:
> 
> After all move doesn't fill the target field, it overlays (with conversion
> if needed) a part of it.  Eval on the other hand always changes the entire
> target field and always begins at the first position of the source and
> target.  Since no calculations are involved with Eval the compiler probably
> doesn't bother to check for overlaps since it has no impact.
> 
> Move is also a "legacy" op-code.  Moving overlapping fields back in the days
> of the S/3, 34 and 36 would (if memory serves) have a different effect to
> that on 400s and iSeries.  It may be because of that that move is defined as
> not permitting overlaps and hence the compiler error.
> 

Actually, EVAL could have problems with overlapping fields too, but it
handles them if there's a possibility the fields might overlap.  Fields
can overlap explicitly by being overlapping subfields of a data
structure, and they can also overlap physically through reference
parameters or based variables.  (We see cases of parameters overlapping
all the time when too-short parameters are passed from the command
line.)

I don't know the history of the no-overlap rule, but it applies to most
(all?) of the fixed-form opcodes, Z-ADD, CAT etc.

I don't know for sure why EVAL was left out of the rule, but I think it
was indeed because it completely fills whatever is specified on the left
hand side (which might not be a complete field in the case of
left-hand-side %SUBST).  It's possible that filling the whole field
would put garbage into any of the other operands of the EVAL operation,
but any operation might put garbage into other storage that overlaps the
target of the operation, so the only thing that is important is that the
pre-operation value of the other operands is used, and not whatever
value they might have during or after the operation.

Although what I just said about always using the pre-operation value of
the other operands is entirely true - somewhere in the manuals it says
that if you pass a parameter by reference to a procedure as part of an
expression, and the parameter gets updated, and you also use the
parameters as another operand of the eval operation, it's undefined
whether the initial value or the updated value of the parameter would be
used.

For example 
  y = 3;
  x = y + modifyParm(y) + y;
This probably wouldn't use 3 for all the "y" operands if the procedure
changes its parameter.

The same thing could happen if you called a procedure and it modified a
global variable.
  y = 3;
  x = y + modifyY() + y;
This probably wouldn't use 3 for all the "y" operands if the procedure
changes global variable Y.