2013/4/7 Tobias Burnus <bur...@net-b.de>: >>> 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 "7.2.2.4 > Procedure pointer assignment")
Ok, here is an updated patch, which does the discussed checking for
procedure pointer assignments. For this I have introduced a new
function 'gfc_explicit_interface_required', which checks all the items
in F08:12.4.2.2 and is loosely based on the present checks in
'resolve_global_procedure' (which are replaced by the new function).
I hope the general idea of the patch is ok and the error messages are
sufficiently comprehensible.
One leftover problem: The patch currently fails on the auto_char_len_4
test case, which is not being rejected any more. Actually I'm not
fully convinced that the dg-errors there are correct: If the EXTERNAL
statements in auto_char_len_{1,2} do not trigger an "explicit
interface required" warning, I don't see why the ones in
auto_char_len_4 should. Maybe the errors should not be about requiring
an explicit interface, but rather about a mismatch in the interface
(constant vs variable char len)?
Cheers,
Janus
pr56261_v4.diff
Description: Binary data
proc_ptr_40.f90
Description: Binary data
