http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740
--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-02 19:52:17 UTC --- (In reply to comment #7) > Ok, I think the only way this half-sentence and the interpretation on the J3 > mailing list make sense, is via the following interpretation. I disagree and start to come to the conclusion that one should asked at the J3 mailing list - I just have no idea how to ask sensible for the proc-target part of C551. > Consider: > integer, pointer :: lhs, rhs > lhs => rhs > > In such a pointer assignment statement, the object on the right hand side > supposedly does not have the pointer attribute Why? I see on the right hand side a "data-target" looks perfectly like a pointer and matches also the definition "Entities with the POINTER attribute can be associated with different data objects or procedures during execution of a program." I could do: rhs => targer while (even if rhs were an array) I could not do rhs(4) => target > that 'lhs' will point to the target of 'rhs'). With this reading, C551 can be > applied to (proc-/data-)pointer assignments as well, and the sentence about > 'proc-target' does make sense. Well, it makes sense here - but you open at the same time the box of the Pandora. > Also, from a "common sense" POV, it is important to reject protected pointers > on the rhs of a pointer assignment, otherwise the PROTECTED feature could be > circumvented this way. Actually: How? I see how you can modify the pointer target - but not the pointer itself. Thus: - I think C551's "or proc-target" does not make sense as it is unreachable - With regards to C551/C552 gfortan handles it seemingly correctly - I need a stronger coffee when reading the fine prints of the Fortran standard With your definition, you allow for: pointer :: ptr2 => ptr1 which is difficult to get correct and I believe is invalid as "ptr1" has the POINTER and not the TARGET attribute. A POINTER is allowed for a normal, non-initialization expression.
