[Patch] Fortran: Fix 'name' bound size [PR99688]
Jerry DeLisle
jvdelisle@charter.net
Mon Mar 22 00:25:56 GMT 2021
Hi Tobias and others,
Reembering some of my own history, we always have used a +1 on
'LENGTH_MAX' items to allow the C null termination on strings or buffers
for obvious reasons.
Certainly OK for trunk and backports.
Regards,
Jerry
On 3/21/21 9:08 AM, Tobias Burnus wrote:
> The gfc_match_select_rank issue showed up in the testsuite
> and was found by Martin's asan-bootstrapped GCC. First
> analysis by Harald – thanks to both!
>
> However, I think the other variables I fixed were also
> prone to overflows; see below for its usage.
>
> OK for mainline? Other branches?
>
> Tobias
>
> PS: Other pending Fortran patches – please review!
> [Patch] Fortran: Fix intrinsic null() handling [PR99651]
> [Patch] Fortran: Fix func decl mismatch [PR93660]
>
> PPS: Usage of 'name' in the patched functions:
>
> resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
> char name[GFC_MAX_SYMBOL_LEN];
> ...
> sprintf (name, "__tmp_class_%s", c->ts.u.derived->name);
>
>
> select_intrinsic_set_tmp (gfc_typespec *ts)
> {
> char name[GFC_MAX_SYMBOL_LEN];
> ...
> sprintf (name, "__tmp_class_%s", ts->u.derived->name);
>
>
> gfc_match_select_type (void)
> ...
> char name[GFC_MAX_SYMBOL_LEN];
> ...
> m = gfc_match (" %n => %e", name, &expr2);
>
> gfc_match_select_rank (void)
> ...
> char name[GFC_MAX_SYMBOL_LEN];
> ...
> m = gfc_match (" %n => %e", name, &expr2);
>
More information about the Gcc-patches
mailing list