(j3.2006) does move_alloc violate restrictions in 188.8.131.52?
Wed Oct 28 14:30:34 EDT 2009
> The rules in 184.108.40.206 (and elsewhere in the standard) are for
> procedures written in Fortran. Most of the intrinsics, and especially
> ones like MOVE_ALLOC, are most likely not written in Fortran.
Nice shelter by "not written in Fortran". So assume foo is written in C,
then "call foo(a, a)" is perfectly legal by this definition even though
you know foo assigns 1 to its first argument, 2 to the 2nd? -- sigh
> MOVE_ALLOC is probably either inline code, or a C library routine, that
> plays games with the internals of the respective dope vectors for the
> arguments. It was created because you can't do these sorts of things in
Dope vectors are structures, not magic. When dealing with copying data
from one structure to another, there are bounds to be side-effects,
particularly these structures are supposed to do book-keeping the data
> The specific rule in 220.127.116.11, number (2), only talks about references
> to the associated actual argument through the dummy argument or its
> values being affected. Even if there were dummy arguments in the
> Fortran sense, these restrictions would not seem to apply to MOVE_ALLOC.
> The allocatable arguments themselves are not referenced or defined -
> the operations are on the dope vectors.
I doubt it's irrelevant. Normally you don't have this sort of problem
with allocatables, since by default they're making copies. Only pointers
need to be guarded against these side-effects. That's why pointers are
explicitly spelled out in this section. This MOVE_ALLOC is very much like
pointer in this aspect. If you're familiar with C++'s auto_ptr, I'd say
MOVE_ALLOC is nearly identical, in functionality, to assigning one
auto_ptr to another. The side-effect is obvious here. It looks like we
may have to explicitly add MOVE_ALLOC to 18.104.22.168 as an exception.
XL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444 Tie-line 313-3444
email: jimxia at ca.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3