2012/1/18 Tomas Hajny <xhaj...@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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
