🚀 go-pugleaf

In article <jgkDKMn2x.2KA@netcom.com> Joe Keane <jgk@netcom.com> writes:
>In article <DKIp84.9Az@calcite.rhyolite.com>
>Vernon Schryver <vjs@calcite.rhyolite.com> writes:
>>Fooey.  Does SCO support more than one byte order in binary releases?
>>Name an applications that uses XDR or ANS.1 for its disk data.  How many
>>applications can you name that keep non-trivial amounts of data in ASCII
>>to avoid byte order problems?  It is possible to write your applications
>>so that their disk data is host byte-order independent.  It is almost
>>never done because its costs in code size, execution time, development
>>time, and long term bug fixing are each, seperately, intolerably high.
>
>Sorry, but this is baloney.  The real reasons are ignorance and laziness.
>The other reasons are good excuses but they don't hold up under scrutiny.
>
>At some point, or maybe not, the light goes on in a programmer's head, that
>read and write operate on *bytes* and maybe you should use them that way.

I think that is wrong.  

>Blasting structures directly to disk or the network is just bad practice.
>
>Important files and network data should have a real, well-defined format;
>they shouldn't just be a core dump of whatever was in memory at the time.
>Saying `but it works on my machine' isn't a sign of a competent programmer.
>
>Byte order is hardly the only problem; there are also differing type sizes
>and structure padding.  Even on the same machine, these change when you use
>a different compiler or compiler options.

I agree with practically all of that.

>                                           Code that depends on such things
>will cause incompatibility again and again, but people will not learn.
>
>C++ objects add even more problems.  Besides the problems above, there are
>virtual table pointers and virtual base pointers, which clearly can't work,
>plus you don't even know what order the attributes will be stored in.
>
>What if GIF files didn't work between machines?  Or what about tar files?
>What if you compress a file and can't uncompress it on a different machine?
>People would say that someone is an incompetent bozo, and they'd be right.

No, that is wrong.

Contemplate the byte-order dependencies in the tar.  There are programs
that can read and write all of the common cpio and tar formats, and
these programs can be compiled to run on either big or little endian
machines.  Nevertheless, neither tar nor cpio use XDR or ANS.1.  Also
consider the fact that the LZW encoding used in GIF files is big-endian.

Backups are almost as good case study as network data of why people
with clues rarely use byte-order independent formats.  You do not
fondle the data so that it is self-describing and independent of (what
you naively imagine are) all possible variations.  Instead, you pick
a reasonable format, paying attention to alignment, packing, and so
forth for a variety of machines, compilers, etc. covering your target.
Then you add a version number to the structure and cast it in stone.

Yes, some rare times you do use XDR and ANS.1, when the balance between
(supposedly) universal decoding and speed favors the former, as in
the NFS control information (which uses XDR).  Notice that the main
bits carried by NFS, the file data, are byte-order dependent.
Yes, you often use ASCII, but only for trivial amounts of data
or when speed is irrelevant, as in toys or log files.


>Performance is a fine excuse but, take it from me, it's just an excuse.

Have you ever looked at code where speed matters?  For example, consider
the fact that in RPC protocols, the performance bottleneck is generally
in marshalling and unmarshalling.  NDL compilers and rpcgen continues
to be a topic for papers, just because of the costs of universal
encodings.

The original subject was whether it is reasonable for NT to pick only
little-endian.  My quoted words above are a rant against ASCII, ANS.1,
or XDR for byte-order independence.  Are you really arguing against
either of those positions?


Vernon Schryver    vjs@rhyolite.com