[SDL] Get pixel value ...more in details

winterlion winterlion at fsj.net
Tue Aug 28 02:11:00 PDT 2001


On Mon, 27 Aug 2001, Kylotan wrote:

> > > res = (int)r;
> > > res |= (int)g << 8;
> > > res |= (int)b << 16;
> >
> > Integer promotion rules make these casts redundant.  Replace 'int'
> with
> > 'Uint32', and they'll be correct and no longer redundant.
>
> Are these rules mandated by the Standard (and if so, is it the same for
> C and C++), or are they just something that 'most' compilers do?
> Personally I don't see why the left value in a shift expression would be
> promoted to the type of the value on the right. It makes sense for
> arithmetic operators but not for shift operators. For example, where's
> the sense in having ((char)100 << (long)14) and ((char)100 << (short)14)
> yielding different results?

yes - these are pretty much mandatory.. (see other posts people made)

also sign extension can cause funny things... in signed char, bit 8 is the
sign bit and if you want to -keep- ranges 0x80-0xff valid you want
unsigned...

(char)100 << (sometype)14) = // thinking unusual circumstances
	if kept char (or short); result = 0... or -1...
	if unsigned char (or unsigned short); result's probably 0
	if promoted to int (or larger): 0x190000

and IIRC, the left is promoted to the type of the result... or was it
-always- promoted to int, then downgraded to the lvalue?  I canna
remember..  (gnu always promotes to int/Uint32 IIRC)

and note for fun to those folks translating from MASM-style assembly that
SHL and SAL are different (shift left and arithetic shift left) although
apparently SHR/SAR are more trouble... (referring to TASM 3.0 manual :)
(SAL/SAR use the sign bit, SHL/SHR consider it a normal bit)

G'day, eh? :)
	- Teunis





More information about the SDL mailing list