[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch #9620] spurious compiler warning: "potential null pointer der
From: |
Akim Demaille |
Subject: |
Re: [patch #9620] spurious compiler warning: "potential null pointer dereference" |
Date: |
Sat, 12 May 2018 09:05:47 +0200 |
> Le 11 mai 2018 à 05:19, Frank Heckenbach <address@hidden> a écrit :
>
> Akim Demaille wrote:
>
>>> I also find the code a bit strange at all; why have a number of format
>>> strings
>>> that differ only in the number of "or %s" parts, and which must all be
>>> translated individually? Rather than adding repeated parts in a loop, or
>>> using
>>> a more flexible wording such as "expecing one of the following: « ?
>>
>> Because of internationalization: you don't know how it would be
>> translated, how punctuation would be, etc.
>
> In my suggestion only the text "expecing one of the following:"
> would need to be translated.
Yes, I see that, but it seems less natural, and will require
special treatment for the case 1 anyway.
So far everybody agreed that if there are too many options,
listing them is useless, so that « limitation » is not a real
one, it is a feature. Would you agree with that?
> It would be followed by a list of
> tokens only, with no more text. Since token names themselves are not
> translated either AFAIK,
No, they are not, indeed.
> the separator doesn't need to be (i.e.,
> even if some language uses some other than commas to separate lists,
> it would be strange to use them in a list of English token names).
> If that's really problematic, it will be hard for internationalized
> programs to output any lists at all ...
>
>>> Anyway, this patch does just the minimum necessary to avoid the warning (and
>>> make the code more robust in case someone changes
>>> YYERROR_VERBOSE_ARGS_MAXIMUM), by using "default" instead of "case 0 ».
>>
>> But it would be incorrect anyway.
>
> I think not strictly incorrect. It would just default to outputting
> no token names (as it's currently supposed to do in this case,
> anyway).
Yes. I meant « incorrect » more in the sense of « inconsistent ».
The behavior would not be visibility wrong for the user, but not
what the developer would have expected. I’m referring to the same
things than you in:
> Actually I do find the code rather fragile; the definition of
> YYERROR_VERBOSE_ARGS_MAXIMUM does not even have a comment pointing out the
> ramifications of changing it.
>> Would `default: abort` suit you?
>
> Mostly what bothers me is the compiler warning, so anything that
> avoids that is basically fine with me.
I’ll try that then.