Re: Error UTF-8 strings
Akim Demaille <[email protected]>
| Newsgroups | gmane.comp.parsers.bison.bugs |
|---|---|
| Message-ID | <[email protected]> |
Hans, > Le 22 juin 2020 à 10:40, Hans Åberg <[email protected]> a écrit : > >> On 22 Jun 2020, at 07:59, Akim Demaille <[email protected]> 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.