Re: [Q] Text vs Binary Files

From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: 08/28/04 

Date: Sat, 28 Aug 2004 12:06:46 -0400 (EDT)

On Sat, 28 Aug 2004, Donald Roby wrote:
>
> On Fri, 28 May 2004 10:05:35 -0400, Arthur J. O'Dwyer wrote:
>> *Again* I urge the consultation of the RFCs defining any standard
>> binary file format, and the notice of the complete lack of regard
>> for big-endian/little-endian/19-bit-int/37-bit-int issues. At the
>> byte level, these things simply never come up.
>
> Try (for example) RFC 1314.

[RFC defining among other things a subset(?) of the TIFF image
file format]

> These things certainly do come up, and they're handled by
> encoding the rules in a header of the format.

   Not really. TIFF /is/ weird in that it explicitly provides
both a "big-endian" format and a "little-endian" format, and TIFF
readers have to provide routines to read both formats. But the
endianness/word size of the machine never comes up. If it did,
we wouldn't be able to write TIFF writers or readers that worked
on platforms with different endiannesses. (IIRC, this whole thread
was started way back in the mists of time with the idea that

     fputs("42000\n", fp);

produces different results on different machines (because of the
embedded newline, which produces different bytes on different
systems; not to mention the possibility of EBCDIC!), while

     unsigned int result = 42000;
     unsigned char buffer[8];
     buffer[0] = (result>>24)&0xFF;
     buffer[1] = (result>>16)&0xFF;
     buffer[2] = (result>>8)&0xFF;
     buffer[3] = (result>>0)&0xFF;
     fwrite(buffer, 1, 4, fp);

produces the exact same bytes on every platform. Thus "binary
is better than text" if you care about portability more than
human-readability.

   But since we already had that discussion (several months ago,
IIRC), I'm not going to get back into it.

-Arthur,
signing off

Relevant Pages