public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/95998] New: gfc_typename use of static memory
@ 2020-07-08 12:17 dominiq at lps dot ens.fr
  2020-07-11 17:47 ` [Bug fortran/95998] " tkoenig at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-07-08 12:17 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95998

            Bug ID: 95998
           Summary: gfc_typename use of static memory
           Product: gcc
           Version: unknown
            Status: WAITING
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---
            Status: WAITING
  Last reconfirmed: 2020-07-08
    Ever confirmed: 1

The comment in misc.c says it all...

/* Return a string describing the type and kind of a typespec.  Because
   we return alternating buffers, this subroutine can appear twice in
   the argument list of a single statement.  */

Did we really audit our code to make sure we keep to this restriction? :-|

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Is static in C/C++ equivalent of SAVE in fortran (at least in the context of
gfc_typename)?

If yes, AFAIU the code the odd access to gfc_typename use buffer2, while even
ones
use buffer1? Wouldn't it be simple (safer?) to use only buffer1?

  static char buffer[GFC_MAX_SYMBOL_LEN + 7];  /* 7 for "TYPE()" + '\0'.  */
  gfc_typespec *ts1;
  gfc_charlen_t length = 0;

Same thing for gfc_dummy_typename, gfc_typename, ... .

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/95998] gfc_typename use of static memory
  2020-07-08 12:17 [Bug fortran/95998] New: gfc_typename use of static memory dominiq at lps dot ens.fr
@ 2020-07-11 17:47 ` tkoenig at gcc dot gnu.org
  2020-07-12  8:46 ` dominiq at lps dot ens.fr
  2021-03-28 12:33 ` dominiq at lps dot ens.fr
  2 siblings, 0 replies; 4+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2020-07-11 17:47 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95998

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #1)
> Is static in C/C++ equivalent of SAVE in fortran (at least in the context of
> gfc_typename)?

Yes.

> If yes, AFAIU the code the odd access to gfc_typename use buffer2, while
> even ones
> use buffer1? Wouldn't it be simple (safer?) to use only buffer1?
> 
>   static char buffer[GFC_MAX_SYMBOL_LEN + 7];  /* 7 for "TYPE()" + '\0'.  */
>   gfc_typespec *ts1;
>   gfc_charlen_t length = 0;
> 
> Same thing for gfc_dummy_typename, gfc_typename, ... .

If we ever have three occurences of gfc_typename in a function list,
like

   foo (gfc_typename(a), gfc_typename(b), gfc_typename(c));

we will get the wrong result for the third one.  We will also get
a wrong result for

   pa = gfc_typename(a);
   pb = gfc_typename(b);
   pc = gfc_typename(c);

because then pa will point to the same memory as pc.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/95998] gfc_typename use of static memory
  2020-07-08 12:17 [Bug fortran/95998] New: gfc_typename use of static memory dominiq at lps dot ens.fr
  2020-07-11 17:47 ` [Bug fortran/95998] " tkoenig at gcc dot gnu.org
@ 2020-07-12  8:46 ` dominiq at lps dot ens.fr
  2021-03-28 12:33 ` dominiq at lps dot ens.fr
  2 siblings, 0 replies; 4+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-07-12  8:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95998

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> If we ever have three occurences of gfc_typename in a function list,
> like
>
>   foo (gfc_typename(a), gfc_typename(b), gfc_typename(c));
>
> we will get the wrong result for the third one.  We will also get
> a wrong result for
>
>   pa = gfc_typename(a);
>   pb = gfc_typename(b);
>   pc = gfc_typename(c);
>
> because then pa will point to the same memory as pc.

OK. I think I am now starting to understand how this proc works.

I have looked at the occurrences of gfc_typename, and AFAICT they appear only
once or twice within
the same gfc_error, except for (line 2303 in check.c)

     gfc_error ("The function passed as OPERATOR at %L has arguments of type "
                 "%s and %s but shall have type %s", &op->where,
                 gfc_typename (&formal->sym->ts),
                 gfc_typename (&formal->next->sym->ts), gfc_typename (a));

but 'a' is a gfc_expr, while 'formal->sym->ts', and 'formal->next->sym->ts' are
gfc_typespec, so different procs and it should be OK.

Note that presently gfc_typename is only called in error messages and potential
problems will
only show as strange errors.

However in noticed a potential buffer overflow with DEC extensions:

  static char buffer1[GFC_MAX_SYMBOL_LEN + 7];  /* 7 for "TYPE()" + '\0'.  */
  static char buffer2[GFC_MAX_SYMBOL_LEN + 7];

should be

  static char buffer1[GFC_MAX_SYMBOL_LEN + 8];  /* 8 for "UNION()" + '\0'.  */
  static char buffer2[GFC_MAX_SYMBOL_LEN + 8];

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/95998] gfc_typename use of static memory
  2020-07-08 12:17 [Bug fortran/95998] New: gfc_typename use of static memory dominiq at lps dot ens.fr
  2020-07-11 17:47 ` [Bug fortran/95998] " tkoenig at gcc dot gnu.org
  2020-07-12  8:46 ` dominiq at lps dot ens.fr
@ 2021-03-28 12:33 ` dominiq at lps dot ens.fr
  2 siblings, 0 replies; 4+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-03-28 12:33 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95998

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|WAITING                     |RESOLVED

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The off by one problem has been fixed by r11-7873, closing.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-03-28 12:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-08 12:17 [Bug fortran/95998] New: gfc_typename use of static memory dominiq at lps dot ens.fr
2020-07-11 17:47 ` [Bug fortran/95998] " tkoenig at gcc dot gnu.org
2020-07-12  8:46 ` dominiq at lps dot ens.fr
2021-03-28 12:33 ` dominiq at lps dot ens.fr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).