[Toybox] [PATCH] Distinguish 32- and 64-bit variants in file(1) for x32.

[Rob Landley]

On 02/21/2016 03:39 PM, Rich Felker wrote:
> On Sat, Feb 20, 2016 at 02:28:22PM -0600, Rob Landley wrote:
>> On Wed, Feb 17, 2016 at 7:02 PM, enh <enh at google.com> wrote:
>>> On Wed, Feb 17, 2016 at 3:32 PM, Rob Landley <rob at landley.net> wrote:
>>>> On Wed, Feb 17, 2016 at 10:22 AM, enh <enh at google.com> wrote:
>>>>> It's necessary to distinguish x86 and x86-64 to be able to recognize the
>>>>> way x32 is encoded in ELF.
>>>>
>>>> Hmmm. That's not fun.
>>>>
>>>> I note that I spent the morning teaching the code to read/display the
>>>> dynamic linker name, so this patch won't "git am" directly.
>>>>
>>>> Reading the patch, we're pretending that arrch64 has nothing to do
>>>> with arm? No mention of arm in this architecture? Ok... (I guess
>>>> Cortex-M isn't arm either, but don't currently have an example binary
>>>> of that to test.)
>>>
>>> well, you're the one who removed my original "ARM aarch64" which is
>>> what the regular desktop file(1) says :-P
>>
>> But not what the linux-kernel developers ever seem to say in their
>> patch submissions.
> 
> Regardless of what you think about these naming choices, IMO there's
> little value in a file(1) that does not print the names that scripts
> using it expect to see.

_What_ scripts? I don't know what would be using this. (All for
real-world tests, but I have yet to find a build script using the file
command. Looking at /proc, sure, but not calling file...)

If the script wants to match "Intel 80386" explicitly, then do I have to
say that for i686?

> The choice to use aarch64 instead of arm64 is
> in some ways also a consequence of this, or rather an intentional
> _mismatch_ with patterns that should not match. The fact that mips64
> and powerpc64 match mips* and powerpc* was historically very
> problematic.

grep -w? Test for 64 bit first?

Elliott was suggesting that the elf-em.h constants might be good enough,
but that says 386 not 80386, and PPC instead of Powerpc...

Seriously, standards would be nice!

(The mime types are designed to be programattically interpreted. The
post here about a mime type database is very interesting and I have a
tab open. But file type output seems to be for humans...?)

> Rich

Rob

 1456108926.0