bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #65053] spurious "hexadecimal escape sequence out of range" warning


From: Vaclav Slavik
Subject: [bug #65053] spurious "hexadecimal escape sequence out of range" warnings
Date: Tue, 19 Dec 2023 12:16:03 -0500 (EST)

URL:
  <https://savannah.gnu.org/bugs/?65053>

                 Summary: spurious "hexadecimal escape sequence out of range"
warnings
                   Group: GNU gettext
               Submitter: 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
         Discussion Lock: Any


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Tue 19 Dec 2023 05:16:01 PM UTC By: Vaclav Slavik <vslavik>
GNU gettext 0.22 introduced a new warning in
0c0345632aedfb254b69f72cce268728113edf2e ("xgettext: In language C, report
out-of-range hexadecimal escapes.").

Unfortunately, the warning is produced even in situations when the code is
correct, because the string or character literal in question is a C++ wchar_t
one. (Notice that the warning is produced for any strings, even those that are
not wrapped in a gettext function and --extract-all is not used.)

Attached is a minimalistic example:

int main()
{
   const wchar_t *test1 = L"1192" L"\x2396" L"59";
   if (c == L'\x02D9')  // U+2009  thin space
       return 1;
   if (c == L'\xff')  // this is ok
       return 0;
   return 0;
}

Corresponding xgettext 0.22.4's output:

$ xgettext -o /dev/null main.cpp  
main.cpp:3: warning: hexadecimal escape sequence out of range
main.cpp:4: warning: hexadecimal escape sequence out of range
$

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.







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65053>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]