This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran, OOP] PR 56261: seg fault call procedure pointer on polymorphic array

Janus Weil wrote:
Thus, the only place where the check can be is for:

   f => ff

In your example, the explicit interface of "ff" is known thus it should be
testable at resolution time of the proc-pointer assignment.
Right. However, strictly speaking, the pointer assignment as such is
probably valid. But of course there is not much one can do with the
proc-ptr afterwards, if it's invalid to call it ...

Well, if one doesn't want to error on it, one can still warn. However, the following states that it is invalid:

"If the characteristics of the pointer object or the pointer target are such that an explicit interface is required, both the pointer object and the pointer target shall have an explicit interface." (F2008, para 4 of " Procedure pointer assignment")

Side note: gfortran currently also accepts:
  external :: qq
  procedure(ff), pointer     :: f => qq
where "ff" has a polymorphic argument.

Another problem is with external procedures, i.e. changing the
proc-ptr definition to a simple PROCEDURE statement (without POINTER).
There one does not have the assignment to check.

Well, we can only bark at the user, when either the procedure pointer or its target has an explicit interface (which uses something which requires an explicit interface). If both are not used, the user is at his own.

However, I assume that in the most common case, the user either forgot to add an interface to the proc-pointer (as in the PR) or mistyped the name of the procedure (which would give a linker error) or forgot to include a module (ditto). In modern code - and proc-pointer and CLASS code is modern - explicit interfaces are usually available. And for same-file procedures, we can even sneak at the gsym which catches those as well.

Thus, while not catching all issues, it will catch a bunch of bugs (and I think even the more common ones). Thus, we should implement the check at some point.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]