>> 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.
>
> Thanks for working on it. It looks mostly okay.
>
> + snprintf (errmsg, err_len, "allocatable argument");
> + return true;
>
> You should use "strncpy" instead of "snprintf". (Unless, you want to append
> ' "%s", arg->sym->name'; however, in this context, the argument name does
> not really matter.) Additionally, please use _("...") to mark it for
> translation.
Done.
>> One leftover problem: The patch currently fails on the auto_char_len_4
>> test case
>
> The patch is okay with the strncpy/_("...") issues fixed.
Thanks, updated version attached.
> Regarding auto_char_len_4.f90: As written in previous email, I think we
> should add a diagnostic for the external declaration ("EXTERNAL,
> CHARACTER(len=<nonconst>", "PROCEDURE(CHARACTER(len=<nonconst>)" (also
> proc-pointer) in resolve_symbol.
I'm not sure if this is the proper thing to do. I guess one problem
would be that such a check in resolve_symbol would also be triggered
by the auto_char_len_{1,2} cases (if it's only based on the EXTERNAL
declaration and not the actual implementation).
I think we should rather do a better correctness-checking of the
interface for global procedures. In fact there already is a check for
the char-len, but it only handles constant lengths. I have now
replaced this by an improved check, which also check constant vs
variable lengths (stolen from "check_result_characteristics" in
interface.c), and this in fact rejects auto_char_len_4.f90.
The new patch regtests cleanly, and I hope it is ok for trunk now(?).
[Btw, I also thought about doing a full "gfc_compare_interfaces" in
"resolve_global_procedure", but that would probably be too strict.]
Cheers,
Janus
pr56261_v5.diff
Description: Binary data
