GNU gettext - Bugs: bug #65053, spurious "hexadecimal escape...
You are not allowed to post comments on this tracker with your current authentication level.
bug #65053: spurious "hexadecimal escape sequence out of range" warnings
Submitter: | Vaclav Slavik <vslavik> | ||
Submitted: | Tue 19 Dec 2023 05:16:01 PM UTC | ||
Category: | Programmer tools | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Sun 31 Dec 2023 12:42:20 PM UTC, comment #4: |
Vaclav Slavik <vslavik> |
Wed 20 Dec 2023 06:37:56 PM UTC, comment #3:
|
Bruno Haible <haible> |
Wed 20 Dec 2023 04:22:06 PM UTC, comment #2: Honestly, both my personal choices I would make when writing new UNIX software or GNU's guidelines for their software are a bit off-topic to the issue. And while I appreciate the non-trivialities of working with wchar_t, calling any use of it not portable is a bit of a stretch (case in point, this sample code is perfectly fine and doesn't hit any of the pain points mentioned in gnulib docs).
|
Vaclav Slavik <vslavik> |
Wed 20 Dec 2023 06:34:38 AM UTC, comment #1: You are aware that programs that make use of L"\x2396" or L'\x02D9' are not portable? Namely to Solaris and FreeBSD.
|
Bruno Haible <haible> |
Tue 19 Dec 2023 05:16:01 PM UTC, original submission:
GNU gettext 0.22 introduced a new warning in 0c0345632aedfb254b69f72cce268728113edf2e ("xgettext: In language C, report out-of-range hexadecimal escapes.").
Corresponding xgettext 0.22.4's output:
These are actually two diffferent misparsings, one in a character literal and one in a string, but what they have in common is that the characted is expected to be < 0xFF, i.e. the parser doesn't recognize these string/character literals as wide ones. |
Vaclav Slavik <vslavik> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Powered by Savane 3.13-02a9.
Corresponding source code
You're obviously the best authority on what your past self meant, but are you sure we're talking about the same change? For reference, this is the commit: https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=0c0345632aedfb254b69f72cce268728113edf2e (and subsequent analog for Vala: https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=dd9a098416034695ad3aed8c22631b9ffaa82d58).
The commit seems very clear that it really is only about actual overflow. The warning message says that. It uses the same wording as a C compiler for actual overflow. The commit message says so (with some extra explanation). The code in phase7_getc() clearly does that, it compares to 0x100. There's no indication anywhere that it is related to portability issues with Solaris or FreeBSD, and every indication that it is about 8-bit character overflow.
By your explanation, the code should warn about any non-ASCII \x sequences, i.e. >= 0x80 as they too are locale-dependent on these platforms. But it doesn't do that and happily accepts them. That seems inconsistent with the portability check purpose as well.
I expected this to be a simple case of phase7_getc() being ignorant of wide characters and just having to use a value different from 0x100 for the check. I mean, the relevant invocation of the function even says so ("We could worry about the 'L' before wide character constants, but ignoring it has no effect unless one of the keywords is "L".") and it was true that it didn't matter before 0c0345632aedfb254b69f72cce268728113edf2e, but does now.
Also, it warns on character literals which are never going to by passed to a gettext function, and are therefore non-issue for portability (by way of sharing common parsing code).
If you think this check is correct and should stay as-is, then I'd say yes, the message definitely could use clarity, because as it is now, it is very misleading. A bogus warning with an obvious workaround is mere annoyance; one with no obvious path to silence it, which looks like a bug to a user, is much worse.
But doing what you suggest is going to be non-trivial and probably not worth the effort: the parser doesn't differentiate narrow and wide literals; it does correctly warn about narrow-char overflows and arguably that's what it should continue to say there; it also accepts some \x escapes in wide-char literals (although that's arguably OK, it doesn't have to warn about every instance...).
I suppose the minimal clarifying change would be something like "hexadecimal escape sequence out of range; use \u in wide-char literal if you meant to designate a Unicode character"? Though you could rightfully complain that such wording steers towards using wchar_t...