This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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


>> 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

Attachment: pr56261_v5.diff
Description: Binary data


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