From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <ee9e417a0601161735g1961295bgee6af7cfb5021a31@mail.gmail.com>
Date: Mon, 16 Jan 2006 20:35:27 -0500
From: Russ Cox <rsc@swtch.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Brdline
In-Reply-To: <20060117005616.DEFB01140E3@dexter-peak.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <15577233041e4238e7a9c8e58d670ddd@terzarima.net>
	<20060117005616.DEFB01140E3@dexter-peak.quanstro.net>
Topicbox-Message-UUID: dac19c48-ead0-11e9-9d60-3106f5b1d025

> likewise, seek takes a vlong "where"so that a -1 "don't care" value can b=
e used.
> this was the source of the sign-extension issue p9p's GBIT64 macro.

seek takes a vlong so that you can seek backwards in a file.
if you replace seek with pread, then you're right, except that -1 doesn't
at all mean "don't care".

> this was the source of the sign-extension issue p9p's GBIT64 macro.

it wasn't.  the original GBIT64 says:

#define=09GBIT64(p)=09((vlong)((p)[0]|...|((p)[3]<<24)) |\
=09=09=09=09((vlong)((p)[4]|...|((p)[7]<<24)) << 32))

and you suggested:

#define=09GBIT64(p)=09((vlong)((ulong)(p)[0]|...|((p)[3]<<24)) |\
=09=09=09=09((vlong)((ulong)(p)[4]|...|((p)[7]<<24)) << 32))

but that won't actually have any effect on systems where
int is 32 bits but long is 64.  the problem is that ((p)[3]<<24)
is being (correctly) treated as a signed int, and then
(vlong)(...|((p)[3]<<24)) sign extends.  Casting the (p)[0]
to (ulong) has the effect of making the whole 32-bit expression
unsigned on 32-bit systems, but if ulong is 64 bits, then
you'll still sign-extend ((p)[3]<<24) during the convertsion
from int to ulong.

the only way i see to fix this is to explicitly cast away the
top bits:

#define=09GBIT64(p)=09((u32int)((p)[0]|...|((p)[3]<<24)) |\
=09=09=09=09((vlong)((p)[4]|...|((p)[7]<<24)) << 32))

this is now fixed on sources and cvs.
russ