9 Apr
2010
9 Apr
'10
10:39 a.m.
On Thu, Apr 8, 2010 at 7:40 PM, John Holden <johnh(a)psych.usyd.edu.au> wrote:
In the PDP-11 long is 32 bits, int 16 bits. And the PDP-11 is
determinedly little-endian if you stick to integers.
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.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
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.
9 Apr
9 Apr
4:23 p.m.
New subject: [pups] extract old archive format?
Carl Lowenstein wrote:
On Thu, Apr 8, 2010 at 7:40 PM, John Holden
<johnh(a)psych.usyd.edu.au> wrote:
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...
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.
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
5370
days inactive
5370
days old
1 comments
2 participants
participants (2)
-
Carl Lowenstein -
Johnny Billquist