[9fans] bizarre 64bit problem

[9fans] bizarre 64bit problem

[erik quanstrom]

this is on p9p with gcc-3.4.4 on a pentiumIII-coppermine.

i've been trying to verify changes in tapefs/tarfs to support
files in a tar archive > 2G. however, i get this:

; 9p ls tapefs
--rw-r--r-- M 0 0 0 -1864421376 Jan 13 09:50 big1.tar

okay, so i changed the print format to %ulld and get this:

; 9p ls tapefs
--rw-r--r-- M 0 0 0 18446744071845130240 Jan 13 09:50 big1.tar

that really doesn't look right so i checked convD2M with gdb:

74		d->length = GBIT64(p);
(gdb) x/8ub p
0x8073ff9:	0	48	223	144	0	0	0	0
$49 = 0
(gdb) p d->length
$50 = 2430545920
(gdb) x/8ub &d->length
0x808408c:	0	48	223	144	0	0	0	0
(gdb) n
80		for(i = 0; i < nstr; i++){
(gdb) n
74		d->length = GBIT64(p);
(gdb) n
75		p += BIT64SZ;
(gdb) x/8ub &d->length
0x808408c:	0	48	223	144	255	255	255	255
(gdb) 

am i getting 4 bytes of sign extension? is the "fix" for this to change GBIT64 to

#define GBIT64(p)	((vlong)GBIT32(p))<<32 | GBIT32(p+4)

- erik

[9fans] bizarre 64bit problem

[erik quanstrom]

gcc is taking each 32bit half as a signed long. i believe that this is the
correct solution for gcc:

#define	GBIT64(p)	((vlong)((ulong)(p)[0]|((p)[1]<<8)|((p)[2]<<16)|((p)[3]<<24)) |\
				((vlong)((ulong)(p)[4]|((p)[5]<<8)|((p)[6]<<16)|((p)[7]<<24)) << 32))

i'd be curious what other compilers do with this.

- erik

erik quanstrom <quanstro@quanstro.net> writes

| 
| this is on p9p with gcc-3.4.4 on a pentiumIII-coppermine.
| 
| i've been trying to verify changes in tapefs/tarfs to support
| files in a tar archive > 2G. however, i get this:
| 
| ; 9p ls tapefs
| --rw-r--r-- M 0 0 0 -1864421376 Jan 13 09:50 big1.tar
| 
[etc]