🚀 go-pugleaf

In article <16329@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>>instead of changing the magic file format to handle BE/LE,
>Too late, I've *already* changed it, and nobody's yet shown any
>disadvantages to doing so....

well, too late for someone

there are two methods being advocated
one changes the magic file data (guy)
and one changes the file command (gsf)
both are valid approaches based on different assumptions

(guy) requires a-priori partitioning of file formats into
big and little endian classes -- the problem here is that
there are some formats that are architecture independent
but still byte order dependent, like the binary cpio format
the solution is to provide duplicate magic file entries:

0	short		070707		cpio archive
0	short		0143561		cpio archive

-or-

0	beshort		070707		cpio archive
0	leshort		070707		cpio archive

(gsf) is based on the assumtion that a byte swapped binary magic number
will not clash with other magic file magic numbers (not a problem so far)
and that the byte order of the first binary test determines the byte
order for the remaining fields for that magic file entry
this method avoids most magic file duplication for formats that cannot
be a-priori labeled BE or LE -- it also handles byte orderings other
then BE and LE (pdp shorts were LE but longs were half LE half BE)

>I just changed all the magic numbers for VAX and i386 "a.out" and COFF
>executables to use "le{short,long}" and all the "a.out" and COFF magic
>numbers for architectures I knew were big-endian to "be{short,long}"; no
>duplication was required there.

you must provide a duplicate entry for binary cpio, no?

>ELF required a little duplication, so that it extracts the various
>fields in the right byte order for the architecture.

elf uses a byte order independent magic string with byte order
dependent fields -- it did require 5 extra lines in our magic file

>That was the *only* duplication required; the same "magic" file works on
>big-endian and little-endian architectures (although you may want to
>change what entries appear if, say, some particular magic number is used
>both for TLA, Inc.'s "a.out" files and FroboTech PLC's "a.out" files).

what about cpu's with byte swap HW jumpers -- does the format change
or just the byte order (not a trick question, I really don't know about
this)

>What happens if you have a field whose value you don't test at all, or
>test with a test other than one for equality or inequality, and whose
>value you later print?

the first magic number in each magic file entry determines the byte
order for all other fields for that entry -- the remaining fields are
swapped to the same order as the magic number as they are snarfed
from the subject file

for example, our cpio magic file entry could be

0	short		070707		cpio archive (magic=0%lo)

and the magic number would be printed 070707 for subject archives
generated on either BE or LE architectures

Glenn Fowler    (908)-582-2195    AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,ucbvax}!ulysses!gsf              internet: gsf@ulysses.att.com