Mail Archives: djgpp/1997/09/07/06:20:10
In article <5ttta0$g3n AT freenet-news DOT carleton DOT ca>, ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire) wrote:
>
>"John M. Aldrich" (fighteer AT cs DOT com) writes:
>> Cesar Scarpini Rabak wrote:
>>>
>>> Text format is not _that_ highly portable! When one switches from
>>> environment the way the end of line is marked varies, and filters or
>>> converting programms may be needed...
>>
>> True. However, a great many programs that I have seen are capable of
>> recognizing EOLs, whatever their format. For example, DOS Edit can load
>> and parse Unix-formatted text files. I guess they're just designed with
>> that in mind.
>
>Yeah and WIndows Notepad can't, even the souped up version with WIndows
>95. :P
>
>> C may not require one, but characters 32-127 of the ASCII character set
>> are pretty well fixed on most systems. I suppose that machines using
>> that IBM format, EDB-whatsit, could cause confusion, but anybody who
>> uses such systems should be aware of the discrepancy.
>
>EBSDIC? Eb's Dick??? Anyone whose computer uses that instead of ASCII,
>should get a newer computer. :)
>
>
I'm surprised that nowere in this thread is the endian problem mentioned. I f
portability of binary files is a requirement, the ordering of bytes in data
types larger than 1 char is an issue. I recently converted a program form a
Motorola platform to Intel in which two very large files were encoded with a
mixture if data types. The encoding program is long gone. I had to modify the
program to change the endian on the fly (a real pain). It is much easier to
run (or write and run) a program to filter the newline characters.
- Raw text -