From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu, erik quanstrom <quanstro@quanstro.net>
References: <20060114040224.6C1231140ED@dexter-peak.quanstro.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <20060114040224.6C1231140ED@dexter-peak.quanstro.net>
Subject: [9fans] bizarre 64bit problem
Message-Id: <20060114051259.DD11D3256A@dexter-peak.quanstro.net>
Date: Fri, 13 Jan 2006 23:12:59 -0600
Cc: 
Topicbox-Message-UUID: d6debeb2-ead0-11e9-9d60-3106f5b1d025

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]