Re: [patch #9620] spurious compiler warning: "potential null pointer dereference"

[Akim Demaille]

> 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.