This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: bug?
- To: Ben Kohlen <bckohlen at yahoo dot com>
- Subject: Re: bug?
- From: Ingo Krabbe <ikrabbe at earthling dot net>
- Date: Sun, 17 Jun 2001 12:00:52 +0200 (CEST)
- cc: <gcc-help at gcc dot gnu dot org>
- Reply-To: Ingo Krabbe <i dot krabbe at dokom dot net>
On Fri, 15 Jun 2001, Ben Kohlen wrote:
> I am expecting that when I shift right, I will always
> get zeroes in from the left, but when I use data types
> less than 32 bits, this is not always the case.
>
> Example:
> ...
> unsigned short s = 0xcc55;
> printf("%x\n", (s<<8)>>8);
> ...
> yeilds the output "cc55" where as I was expecting
> "55".
>
I don't think thats a bug, it is more a question of flavour, of course
it would be very nice to fill 0 into the upper bits. It may be better to
mask them out:
#define CLEAR_UPPER_BITS(n,x) \
((n<sizeof(x)*8) ? x&(~((~(x^x))<<(8*sizeof(x)-n))):0)
This is machine and (numeric) type independent masking out of n upper
bits. For smaller types we can use a 0 instead of x^x. There may be a more
optimized solution ? We can also give a 0 in the right length to the
algorithm:
#define CLEAR_UPPER_BITS(n,x,null) \
((n<sizeof(x)*8) ? x&(~((~(null))<<(8*sizeof(x)-n))):0)
Has anyone a better solution ?
CU INGO