From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <ee9e417a0601161747t4699e7ebsa498139074d9143b@mail.gmail.com>
Date: Mon, 16 Jan 2006 20:47:45 -0500
From: Russ Cox <rsc@swtch.com>
To: erik quanstrom <quanstro@quanstro.net>
Subject: Re: [9fans] Brdline
In-Reply-To: <20060117014256.9D9991140EA@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>
	<ee9e417a0601161735g1961295bgee6af7cfb5021a31@mail.gmail.com>
	<20060117014256.9D9991140EA@dexter-peak.quanstro.net>
Cc: 9fans@cse.psu.edu
Topicbox-Message-UUID: dafd7bdc-ead0-11e9-9d60-3106f5b1d025

> | 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.
>
> i'll be wearing the dope sack over my head this week.

this took me forever to puzzle through, by the way.
the only reason i'm pretty sure it's true is that i tried it!  ;-)

russ