C++ Logo


Advanced search

Re: [SG16-Unicode] It???s Time to Stop Adding New Features for Non-Unicode Execution Encodings in C++

From: Philipp Klaus Krause <krauseph_at_[hidden]>
Date: Mon, 29 Apr 2019 23:54:46 +0200
Am 29.04.19 um 09:28 schrieb Philipp Klaus Krause:
> Am 28.04.19 um 23:25 schrieb JeanHeyd Meneide:
>> I think there's really only one thing that needs to be fixed, and that's
>> the POSIX and C locales. Right now, they force a by-requirement 256
>> single-byte encoding. (Chapter 6, Section 2, first sentence:
>> http://pubs.opengroup.org/onlinepubs/9699919799/).
>> […]
>> POSIX/C need to acknowledge that multibyte encodings are reasonable
>> defaults (not just recommended extensions, but plausible defaults).
>> Until then, no: the C standard does not deliver for all and actively
>> harms the development and growth of international text processing on
>> large and small hardware systems.
> I see the problem with the POSIX locale. But what is the problem with
> the C locale. Is it about iswblank()?
> Philipp

In case you find anything that prevents a UTF-8 C locale in the C
standard, I'd help resolve the issue.

So far, I only see iswblank() as a minor issue (but that only means that
the seldom-used iswblank() would not be particularly useful for a UTF-8
C locale), but nothing that disallows a UTF-8 C lcoale.


Received on 2019-04-29 23:54:51