Bruno Haible wrote:
> Hi Jim,
>
>> I tried enabling -Wvla for coreutils and found that it provoked hundreds
>> of warnings, all due to this:
>>
>> ../lib/gettext.h:262:3: error: variable length array 'msg_ctxt_id'\
>> is used [-Werror=vla]
>>
>> That comes from this inline function from gettext.h:
>>
>> static const char *
>> dcnpgettext_expr (const char *domain,
>> const char *msgctxt, const char *msgid,
>> const char *msgid_plural, unsigned long int n,
>> int category)
>> {
>> size_t msgctxt_len = strlen (msgctxt) + 1;
>> size_t msgid_len = strlen (msgid) + 1;
>> const char *translation;
>> #if _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS
>> char msg_ctxt_id[msgctxt_len + msgid_len];
>> #else
>> ...
>
> Yes, as you can see this code uses variable-length arrays only
> when the compiler supports it.
>
>> Do we have a guarantee that that array dimension is reasonable?
>
> Yes. While msgctxt and msgid normally rarely exceed 1 KB (because
That sounds like convention. Is there a guarantee?
> of the principle to split at paragraph boundaries, so that translators
> can compare an old and a new msgid, for msgids with plural, the
> string is most often only a single sentence, that is, rarely larger
> than 200 bytes.
What I was wondering is whether there were some guard, say
in all callers, that would prevent VLA abuse.
>> Have you compared the trade-offs of VLA-vs-malloc here?
>
> Yes I did.
>
> The problem is that the compiler does not know that I did.
>
> You may want to propose a #pragma diagnostic ignore patch.
Such a #pragma affects a compilation unit, so putting it
in the .h file would affect every .c file that includes it.
Putting such a #pragma in every file from which gettext.h
is included is not really an option.
I can live with the status quo, but it would make -Wvla more useful
not to put such constructs in commonly-included header files.
