Re: [9fans] Brdline

[Russ Cox <rsc@swtch.com>]

> likewise, seek takes a vlong "where"so that a -1 "don't care" value can be 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	GBIT64(p)	((vlong)((p)[0]|...|((p)[3]<<24)) |\
				((vlong)((p)[4]|...|((p)[7]<<24)) << 32))

and you suggested:

#define	GBIT64(p)	((vlong)((ulong)(p)[0]|...|((p)[3]<<24)) |\
				((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	GBIT64(p)	((u32int)((p)[0]|...|((p)[3]<<24)) |\
				((vlong)((p)[4]|...|((p)[7]<<24)) << 32))

this is now fixed on sources and cvs.
russ