🚀 go-pugleaf

>(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

Nope.  Try:

0	short		070707		cpio archive
0	short		0143561		byte-swapped cpio archive

Given that, unfortunately, not all versions of "cpio" are capable of
decoding binary "cpio" files with the opposite byte order, it is
potentially useful to know whether the archive is byte-swapped or not.

>(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)

Actually, I think the old Sun-2 executable format *does* clash with the
VAX BSD executable format - one has 4 bytes of 0407/0410/0413 in
big-endian order at the beginning, the other has them in little-endian
order at the beginning.

>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)

Mine handles that as well, although you would have to use "belong" or
"lelong" with a constant the two halves of which are swapped.

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

Nope.  See above.

>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)

It appears, from some of the magic file entries, that the magic number
changes on at least one MIPS object/executable format.

Besides, I, at least, would want to know whether something is a
big-endian or little-endian Frobozz executable, not just whether it's a
Frobozz executable or not....