[fpc-devel] On a port of Free Pascal to the IBM 370

Felipe Monteiro de Carvalho felipemonteiro.carvalho at gmail.com
Wed Jan 18 17:32:30 CET 2012


2012/1/18 Tomas Hajny <XHajT03 at hajny.biz>:
> As pointed out in my other e-mail, "everywhere necessary" implies either
> "dear user, convert all your files from the original encoding before you
> want programs created in FPC to touch them"

Yes, no problem here. I assume there must be some program in this
platform which can edit ASCII text and another one (or the same) to
convert text files between encodings. If not, just use the new port to
cross-compile such a program =)

> or "dear programmer targetting
> OS/370, make sure that your programs are limited in what RTL functions you
> use, or convert all locally stored files to ASCII and only use the RTL
> functions for text processing on the converted copies". Otherwise even
> stuff like line by line reading or field by field reading of the input
> text file using standard RTL routines may not work as expected with the
> current RTL.

I don't see why. A text encoding is just a text encoding, of the
hundreds of obsolete ones in existence, and the only sane way of
handling text in cross-platform applications is Unicode.

The RTL could ship with UTF-8 <-> EBCDIC convertor and define UTF-8 as
the platform encoding. Detect which exact format the platform is using
at runtime if necessary and convert everywhere necessary. This should
cover all characters possibly imaginable and all control characters
too.

What could go wrong here? This is what Java does in all its platforms.

As for WriteLn / ReadLn if one really wants to allow inputing directly
control codes, one could either make them use UTF-8 and offer an
alternative RawWriteLn / RawReadLn for raw input of control codes or
leave them sending raw text and expose the routines to convert UTF-8
<-> EBCDIC

-- 
Felipe Monteiro de Carvalho



More information about the fpc-devel mailing list