> 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
