4 ms·

> What I mean is that we wouldn't use e.g. libc's "iswdigit" and friends ... because we use those functions, we're beholden to the libc wchar_t type ... which m

> What I mean is that we wouldn't use e.g. libc's "iswdigit" and friends ... because we use those functions, we're beholden to the libc wchar_t type ... which means the difference between cygwin (2 byte wchar_t) and as best as I can tell any other system (4 byte wchar_t) can appear everywhere. Say what now? You can't use a wchar_t with iswdigit() even if you wanted to. And wint_t (the correct type) is 32-bit on every platform I'm aware of, including Cygwin.

jmillikin 4y ago
wint_t represents either a wchar_t or the sentinel value WEOF. You shouldn't pass an arbitrary Unicode codepoint to iswdigit() on platforms with 16-bit wchar_t.
- torstenvl 4y ago
  Perhaps, but then wouldn't the issue just be that iswdigit() is practically useless, rather than that it 'requires' (it doesn't) using a type that may only be 16-bit? Even on systems where wchar_t is 32-bit, that isn't a guarantee that the extended character set supported by iswxxx() includes Unicode. (It also requires your OS to support a large number of locales, which is unlikely. The vast majority of iswxxx() functions are broken on the vast majority of Linux installs.)
  - jmillikin 4y ago
    > Perhaps, but then wouldn't the issue just be that iswdigit() > is practically useless, rather than that it 'requires' (it doesn't) > using a type that may only be 16-bit? In my opinion yes, though obviously opinions vary. When Unicode expanded beyond the BMP, the decision by some platforms (Windows, Java, JavaScript) to represent "wide characters" as 16-bit integers became a problem. APIs that accept strings rather than "characters" could be adjusted from UCS-2 to UTF-16, but anything shaped like iswdigit() needed to be reconsidered. The thing about iswdigit() and friends is that it does mostly do what people expect so long as (1) they don't need to write cross-platform code and (2) their localization needs are simple (BMP only), which is true of like 95% of software, so it can be hard to convince anyone to stop using it in favor of more robust solutions like libicu.

jmillikin 4y ago

wint_t represents either a wchar_t or the sentinel value WEOF. You shouldn't pass an arbitrary Unicode codepoint to iswdigit() on platforms with 16-bit wchar_t.

torstenvl 4y ago
Perhaps, but then wouldn't the issue just be that iswdigit() is practically useless, rather than that it 'requires' (it doesn't) using a type that may only be 16-bit? Even on systems where wchar_t is 32-bit, that isn't a guarantee that the extended character set supported by iswxxx() includes Unicode. (It also requires your OS to support a large number of locales, which is unlikely. The vast majority of iswxxx() functions are broken on the vast majority of Linux installs.)
- jmillikin 4y ago
  > Perhaps, but then wouldn't the issue just be that iswdigit() > is practically useless, rather than that it 'requires' (it doesn't) > using a type that may only be 16-bit? In my opinion yes, though obviously opinions vary. When Unicode expanded beyond the BMP, the decision by some platforms (Windows, Java, JavaScript) to represent "wide characters" as 16-bit integers became a problem. APIs that accept strings rather than "characters" could be adjusted from UCS-2 to UTF-16, but anything shaped like iswdigit() needed to be reconsidered. The thing about iswdigit() and friends is that it does mostly do what people expect so long as (1) they don't need to write cross-platform code and (2) their localization needs are simple (BMP only), which is true of like 95% of software, so it can be hard to convince anyone to stop using it in favor of more robust solutions like libicu.