Am 13.02.2022 um 19:25 schrieb Achim Gratz:
Gans, Markus writes:
This seems to be an internal Cygwin error:
https://www.reddit.com/r/cpp_questions/comments/sp52gq/xdigit_does_not_work_with_stdwstring_in_a_cygwin/
[…]
Question: Why does Cygwin not detect the letters a, b, c, d, e, and
f as hexadecimal digits in a wide string?
[...]
There is no OS specific configuration for Cygwin explicitly, instead
there is one for newlib that actually gets used.
This piqued my curiosity, so I had a look at how libstdc++ is built. I
found that at least for one crucial source file, called
ctype_members.cc, cygwin builds do _not_ use the newlib edition, but
rather the "generic" one. And that may very well be the problem here.
The superficial cause of the problem is that member function
_M_initialize_ctype() in
libstdc++-v3/config/locale/generic/ctype_member.cc fills most of its
array _M_wmask[] with zeroes instead of meaningful character class
identifiers.
The slightly deeper reason is that the companion array _M_bit[] is also
suspiciously full of zeroes.
But the real problem, IMHO, is that the type ctype<wchar_t>::mask is
just a plain char. That overflows the looped shift used to fill
_M_bit[], which in turn leads to nonsense in _M_wmask[].
I didn't manage to find where this ctype<wchar_t>::mask is defined, but
the way it's used here cannot work if it's defined as plain char. The
newlib edition of ctype_members.cc loops over just 8 bits instead of
16, which would allow this to work.
So we either have to pick up a different type definition of
ctype<wchar_t>::mask, or a different edition of ctype_members.cc --- I
guess it should be the newlib one.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
