[WalterBright]

IBM can support it as an extension in their C++ compiler. No need to burden the rest of the community with it. It's not like C++ compiler vendors are shy about adding extensions :-)

Despite C++ supporting EBCDIC, I seriously doubt the overwhelming majority of string processing C++ code will work with EBCDIC anyway, because the programmers probably never heard of it, let alone tested the software with it.

[jcelerier]

> No need to burden the rest of the community with it.

yeah, the problem is when IBM goes with big checks to national standard bodies and complains "muuuuhh we won't be able to assure that the systems we sold you in 1970 will still work in 20 years if the C++ standard removes support for EBCDIC" and then these standard bodies write strongly-worded letters to the ISO commitee: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n291...

[gpderetta]

I think that implying bribery here is dishonest. 6/7th of the authors of the paper are IBM employees and they are just voting according to their employer wills.

[gpderetta]

The Committee recently got rid of trigraphs (required for EBCDIC compatibility). IBM was strongly against the proposal but was finally outvoted. They do keep the functionality as a conforming extension in their compiler, but now that they have been removed from the standard, the language might evolve in ways that might make the extension non-conforming.

[WalterBright]

Trigraphs can be supported with the simple expedient of putting a filter in front of the compiler that converts the trigraph sequences to the corresponding character. It doesn't have to be in the compiler itself.

In fact, trigraphs were designed to operate this way.

That is, until the addition of raw string literals broke that.