Tomas Hajny wrote:
is nothing like translation between ASCII and EBCDIC because there are multiple different character sets for both and real conversion isn't possible without taking this into account and knowing the real character sets which again depends on the context which is again not known at this low level). Unless I'm mistaken, this implies that you indeed need to consider the (basic) EBCDIC layout as an alternative to the (basic) ASCII
If the RTL were fully Unicode-aware then possibly this could be handled by host localisation, presumably on a classic IBM OS the JCL will state unambiguously which variant of EBCDIC is expected.
I think we need to wait for some input from Paul on this one, after all he's the project's instigator.
Not even mentioning the additional "minor" issue with certain characters (critical for Pascal source codes) not necessarily directly available in _some_ (!) EBCDIC character sets as pointed out by Mark - again something which cannot be handled in the general I/O routines because it only becomes important when interpreting a general text as Pascal source code (in this case, special support on the compiler side will be probably necessary, i.e. this should have no impact to RTL, but it will again have impact to the common parts of the compiler, namely scanner, not to target specific units).
I can't remember the source, but my understanding is that Wirth originally worked with an IBM 029 keypunch, possibly connected preparing decks for a CDC. He specifically defined (* and *) as digraphs for { and }, and I think there were others including (. and .) for [ and ] Did FPC /ever/ fully-support these?
-- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
