Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.sources.bugs
Subject: Re: v05i028: /etc/magic lines for compress
Message-ID: <458@auspex.UUCP>
Date: 16 Nov 88 18:07:51 GMT
References: <1033@investor.UUCP> <454@auspex.UUCP> <7714@boring.cwi.nl>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 39

>It is clear that byte order dependencies are a pain, on the other hand
>if for some system some format is specified as 0177767 it appears to be
>backward to have to specify it in the form of a string.

So who says you *have* to specify it in the form of a string?  From the
same SunOS "/etc/magic":

	0	short		0177545		old archive

We didn't *take away* any capability, we just *added* some.

In the case of compressed files, the format *is* properly specified as a
string - in "compress.c", the header is

	char_type magic_header[] = { "\037\235" };	/* 1F 9D */

which sure looks like a string to me....

>Wouldn't it be better to allow specification like AR16W, AR32W and
>AR32WR as happens in so many places in SysV (COFF comes to mind)?

In this particular example, no, it wouldn't be better; since the magic
number for compressed files *is* a string, the right way to specify it is
as a string.

The same applies for packed data:

	0	string		\037\036	packed data

Although PACKED is #defined as 017436 in "pack.c", that #define is not,
in fact, used; the code to generate the magic number is

	outbuff[0] = 037;
	outbuff[1] = 036;

which is, again, a string "\037\036".

The right tool for the right job; telling "file" about a machine's byte
order is, in this case, entirely the wrong tool.