Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: v05i028: /etc/magic lines for compress
Message-ID: <485@auspex.UUCP>
Date: 22 Nov 88 01:40:41 GMT
References: <1033@investor.UUCP> <454@auspex.UUCP> <7714@boring.cwi.nl> <6021@columbia.edu> <470@auspex.UUCP> <6040@columbia.edu>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 35

>Of course, the right solution is to support both.

Agreed.  The problem is that the original assertions about the relative
merits of something saying "big-endian long"/"little-endian long" vs. 
"string" were made with little context, so it was not at all obvious for
which situations it was being considered better; the original topic of
discussion was entries for compressed files, and for those strings are
clearly the way to go.

At the time the S5R2 "file" was put into SunOS, the immediate need for
extensions of that sort was for changes to handle compressed files and
"archive random librar(ies)", which called for extensions to type
"string" rather than for standard-byte-order integral types.  Since (at
that time) all machines from Sun had the same byte order, and since most
other machines were unlikely to have adopted that version of "file", no
support for "standard byte order" integral quantities in files was
added.  (The goal wasn't to make the "perfect" version of "file", the
goal was to add support for compressed files in such a form as to be at
least marginally useful for other things.)

I don't see the need for anything more than types such as "long-be",
"long-le", "short-be", and "short-le", which refer to "long"s stored in
"big-endian" form, etc. (the names seem a bit clumsy; although they're a
bit more obvious than COFFisms such as "AR32W", the "-be", etc. don't
sound quite right).  Basically, "file" would grab 2 or 4 bytes and
convert them to a number in the appropriate format; this would then be
compared against constants, masked, printed, etc. just like "native"
byte-order items such as "long" and "short".  There seems to be no need
to print "standard byte order" quantities any differently from "native
byte order" quantities, or to play games with the byte ordering of masks
or constants to compare those quantities with.

Of course, once you've done that, you can start worrying about 64-bit
machines, and machines with non-8-bit bytes, and the like (at least one
of the former, and at least one of the latter, run UNIX).