https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Pekka S <p...@gcc-bugzilla.mail.kapsi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |p...@gcc-bugzilla.mail.kaps | |i.fi --- Comment #14 from Pekka S <p...@gcc-bugzilla.mail.kapsi.fi> --- (In reply to Jonathan Wakely from comment #6) > (In reply to Jonathan Wakely from comment #5) > > static const mask blank = space; > > We might want to use blank = _ISspace | _ISblank for this last one, but I > don't really understand what newlib defines those categories as: > > > #define isblank(__c) \ > __extension__ ({ __typeof__ (__c) __x = (__c); \ > (__ctype_lookup(__x)&_B) || (int) (__x) == '\t';}) > (__ctype_lookup(__x)&_ISblank) || (int) (__x) == '\t';}) > > This definition is weird ... why is '\t' not already handled by _ISblank? It has been attempted in the past: https://sourceware.org/legacy-ml/newlib/2009/threads.html#00342 The used 8-bit mask is simply not wide enough to disambiguate all POSIX character classes; Namely space, blank and print classes are the problematic ones to distinguish properly. The naming of newlib character classes does not fully align with POSIX, and this has to do with the restrictions that come from space concerns and limitations. Also, libstdc++-v3/config/locale/newlib/ctype_members.cc does not handle blank class even though newlib supports wctype("blank"). As explained above, in this case it really doesn't matter, since matching a character to a (true POSIX) class using a mask bit alone is not possible. Anyway, I made a similar patch but never got around submitting it. I also used _ISblank | _ISspace since IMHO it is "less wrong" than _ISspace (or equal to space) alone and added a note explaining the issue. (Yes, I was about to repeat the history.)