When passing expressions to/from functions and SBX subroutines, if the target is type X, use a physical rather than logical transfer. This matches the behavior of assignments, and closes a loophole that previously occurred when the source expression was of the form VAR[x;y] or VAR[x,y] where VAR was of type X. Previously the transfer was being terminated at the first null even when the target variable was of type X.
Note that this change affects all variations of XGETARG and XPUTARG, as well as implicit parameter passing to functions/procedures, potentially changing the runtime behavior of existing compiled programs, but only in cases where a string or non-numeric expression is passed to an X type variable. Given the narrow range of situations affected, and our belief that the new behavior is more in line with how programmers thought that it had been working all along, not to mention the fact that it is now consistent with the assignment statement logic, we feel that the upside of the change overwhelms the downside. Nevertheless, at least for now, we are not treating it as a bug fix and therefore not planning to retrofit into the stable 6.4 release. Programmers concerned about whether this might affect them are advised to do a global source code search for occurrences of "[" within an XCALL or func/proc call parameter list, as well as within any "PUTARG" statement and then check to see whether the receiving variable is of type X and whether you are counting on the expression being terminated by the first null.
