On 12/7/20 3:43 AM, Philipp Klaus Krause via SG16 wrote:
> Am 06.12.20 um 23:41 schrieb Tom Honermann via SG16:
>
>> * WG14: Improve support for Unicode characters in identifiers
>> <https://github.com/sg16-unicode/sg16/issues/56>
> Will there be problems for EBCDIC systems? AFAIK, C++ dropped support
> for EBCDIC the moment there was no IBM representative in WG14. But C
> still supports it.

Nothing in the C++ standard has been changed that would prohibit use of
EBCDIC as source file encoding, internal compiler encoding, execution
encoding, locale sensitive run-time encoding, filesystem encoding,
terminal encoding, or any of the other encodings acknowledged (or not
acknowledged) by the standard.

IBM does maintain representation in WG21 (and I thought in WG14 as
well). There are also ports of Clang to EBCDIC systems now as well.

>
> Philipp
>
> P.S.: A related topic, but far less ambitious: Would it make sense to
> add @ and $ to the basic source character set
> (http://www.colecovision.eu/stuff/proposal-basic-_at_[hidden])? AFAIK, this
> should work for implementations that use ASCII (or an extension, such as
> UTF-8) as well as those that use an EBCDIC code page that can be used
> for C programming today.

I thought there are some EBCDIC code pages that lack support for these
characters, but it may be that those code pages also lack support for
existing members of the basic source character set. I'm not sure.

I think the direction we're heading in is to specify UTF-8 as a portable
source file encoding. That will not only get us many more portable
characters (effectively all of them), but will also give us a portable
encoding; a stronger guarantee than a portable character set.

Tom.