[Bug c/99280] New: argument to warning_n must be a string literal

["roland.illig at gmx dot de" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 99280
           Summary: argument to warning_n must be a string literal
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: roland.illig at gmx dot de
  Target Milestone: ---

builtins.c says (in condensed form):
> warning_n(
>   loc, OPT_Wstringop_overread, tree_to_uhwi(range[0]),
>   (maybe
>    ? G_("%K%qD may reade %E byte from a region of size %E")
>    : G_("%K%qD reading %E byte from a region of size %E")),
>   (maybe
>    ? G_("%K%qD may read %E bytes from a region of size %E")
>    : G_("%K%qD reading %E bytes from a region of size %E")),
>   exp, func, range[0], size);

The format strings to warning_n are not string literals.  Therefore xgettext
does not recognize them as plural messages, and they show up in Poedit and
other editors as ordinary singular messages.  Marking them with G_ is a
workaround, but that works only halfway.  The message is indeed translated, but
not in the correct plural form.

For German and French this does not matter since their plural forms for n > 0
are the same as in English.  But for Polish or Russian it makes a difference,
and the Russian translation is actively maintained.

Maybe it is possible to teach xgettext to correctly analyze not only string
literals but also the expression 'identifier ? "literal1" : "literal2".  If
that is not possible, the (only?) correct solution may be to duplicate even
more of this code.  That would mean more concentrated work for both the
programmers and the translators since it is really difficult to avoid
copy-and-paste mistakes with all these similar messages.  Typing each message
on its own also increases the chances of typos, which makes the current
situation not perfect.  Maybe that can be improved.