On Wed, January 18, 2012 13:56, [email protected] wrote: > On Wed, 18 Jan 2012, Tomas Hajny wrote: > >>> But then you are assuming the RTL should be using EBCDIC internally as >>> well ? >>> Obviously, that will be a lot more work. >>> >>> But I don't think this should be so. >> >> I may be overlooking something, of course. However: Our RTL is based on >> common (target specific) routines for reading (and writing) text and >> binary files (do_read & do_write). You cannot translate between ASCII >> and >> EBCDID in these target specific routines because you don't know how the >> input would be used at that point (not even mentioning the fact that >> there >> 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). > > Once more: I do not think this is the task of the RTL. FPC and the RTL > works > with ASCII. That includes the expected contents of text files and whatnot. > > That a hypothetical FPC program opening an EBCDIC file on OS/370 needs to > convert this to ASCII first is in my view the responsability of the > programmer. > > The same goes for the FPC sources. > I do not suppose that a FPC port would first convert the current ASCII > sources to EBCDIC, but would continue to use the ASCII version. > > If you define the RTL as being able to handle EBCDIC on OS/370, > it is a different matter, and a lot more work.
OK, could be, but not being able to work with text files created on that platform without additional effort on the _programmer_ side (not the RTL porter side because the RTL porter cannot address this easily within our current RTL structure as pointed out above) would hinder usability of such a compiler _a_lot_. It's certainly possible to start with that, but keeping it that way in longer term would considerably decrease the value of such undergoing in my opinion. Tomas _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
