------- Comment #3 from anlauf at gmx dot de 2008-05-20 18:43 ------- (In reply to comment #2) > However, I would claim that the program is valid as neither obs nor objs(n)%x > itself is changed, but only the target to which objs(n)%x points to.
I see. If component x were an allocatable instead of a pointer, would I then get an error? It might be useful to emit a warning when -Wsurprising (or some other option turned on by -Wall) is enabled. In that case feel free to change the title appropriately, otherwise you may close this report as invalid. Sorry for the noise > * * * > > If a dummy argument is a derived-type object with a pointer component, then > the > pointer as a pointer is a subobject of the dummy argument, but the target of > the pointer is not. Therefore, the restrictions on subobjects of the dummy > object apply to the pointer in contexts where it is used as a pointer, but not > in contexts where it is dereferenced to indicate its target. > > Similarly, the INTENT restrictions on pointer dummy arguments apply only to > the > association of the dummy argument; they do not restrict the operations allowed > on its target. > > A pointer object with the INTENT (IN) attribute shall not appear as > (1) A pointer-object in a nullify-stmt, > (2) A data-pointer-object or proc-pointer-object in a pointer-assignment-stmt, > (3) An allocate-object in an allocate-stmt or deallocate-stmt, or > (4) An actual argument in a reference to a procedure if the associated dummy > argument is a pointer with the INTENT (OUT) or INTENT (INOUT) attribute. I could not yet find this wording in the standard. Do you by chance know the exact verse? The only thing I could find was: [F2003 draft] 5.1.2.7 INTENT attribute [...] The INTENT (IN) attribute for a nonpointer dummy argument specifies that it shall neither be defined nor become undefined during the execution of the procedure. The INTENT (IN) attribute for a pointer dummy argument specifies that during the execution of the procedure its association shall not be changed except that it may become undefined if the target is deallocated other than through the pointer (16.4.2.1.3). Thanks, -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36271
