Re: Error UTF-8 strings

[Akim Demaille]

Hans,

> Le 22 juin 2020 à 10:40, Hans Åberg <haberg-1@telia.com> a écrit :
> 
>> On 22 Jun 2020, at 07:59, Akim Demaille <akim@lrde.epita.fr> wrote:
>> 
>> Hans,
>> 
>> This is double-escaping of the UTF-8 characters is a well known problem
>> of parse.error=verbose, that resulted in the introduction of "detailed"
>> parse.error.  That was discussed extensively on Bison's lists, and is
>> documented in NEWS of 3.6:
>> 
>> 
>> 
>> *** Improved syntax error messages
>> 
>>  Two new values for the %define parse.error variable offer more control to
>>  the user.  Available in all the skeletons (C, C++, Java).
>> 
>> **** %define parse.error detailed
>> 
>>  The behavior of "%define parse.error detailed" is closely resembling that
>>  of "%define parse.error verbose" with a few exceptions.  First, it is safe
>>  to use non-ASCII characters in token aliases (with 'verbose', the result
>>  depends on the locale with which bison was run).  Second, a yysymbol_name
>>  function is exposed to the user, instead of the yytnamerr function and the
>>  yytname table.  Third, token internationalization is supported (see
>>  below).
> 
> The question is if that helps, as it is the yytname_ that is translated 
> according to the LC_CTYPE environment variable.
> 
> This also introduces a locale dependency in the Bison compilation, so that 
> the generated parser no longer is platform independent.

Yes, that is indeed exactly what I meant: verbose is bad, and always was.
Use "detailed" instead.

>> So, there is no new bug in 3.6 here, just something that is well known for
>> ages, about which you and I already discussed.
> 
> Yes, there is, translation dependent on LC_CTYPE, which was not before.

I believe you are mistaken, and you won't find any difference between 3.6
and 3.5 on this regard.

To prove me wrong, give me a reproducible example.