From mboxrd@z Thu Jan  1 00:00:00 1970
From: bqt@softjar.se (Johnny Billquist)
Date: Fri, 09 Apr 2010 12:23:35 +0200
Subject: [pups] extract old archive format?
In-Reply-To: <z2o5904d5731004082139v1498ef52pd36fc318437e04e7@mail.gmail.com>
References: <201004090240.o392eigZ402010@psychwarp.psych.usyd.edu.au>	<n2m5904d5731004082137u5b054823wd4a9ce55113b1dee@mail.gmail.com>
	<z2o5904d5731004082139v1498ef52pd36fc318437e04e7@mail.gmail.com>
Message-ID: <4BBF0027.6060406@softjar.se>

Carl Lowenstein wrote:
> On Thu, Apr 8, 2010 at 7:40 PM, John  Holden <johnh at psych.usyd.edu.au> wrote:
>>> Well I found the ar specification (in ar.5 not ar.1).
>>>
>>>              struct ar_hdr {
>>>                      char      ar_name[14];
>>>                      long      ar_date;
>>>                      char      ar_uid;
>>>                      char      ar_gid;
>>>                      int       ar_mode;
>>>                      long      ar_size;
>>>              };
>> Endian should not be a problem on a Intel/AMD processor. More likely your C
>> compiler is padding out the array for alignment. Try a '-fpack-struct' or
>> more safely, read the elements individually rather than a structure.
>>
> 
> In the PDP-11 long is 32 bits, int 16 bits.   And the PDP-11 is
> determinedly little-endian if you stick to integers.

Um? Longs are integers, and they are middle-endian...

> They got floating-point software right in 1971, but somebody screwed
> up the word order when building FP hardware, which led to the
> middle-endian mess.

...but yes. The middle-endian long issue appeared with the FPP, since 
that is the only hardware that deals natively with long integers.

	Johnny