Re: bitshift of int8, int16, etc?

[Daniel J Sebald]

John W. Eaton wrote:
> On 25-Jun-2007, David Bateman wrote:
>
> | The fact is that as matlab doesn't
> | implement this yet, whatever we choose to do will be wrong in any case
> | and need modifying in the long run. So simple is probably better..
>
> In that case, the simplest (or at least "safest") thing is probably to
> just disable these operations and wait.
>
> But if you want to keep these operators, then I think we should
> definitely avoid doing anything where the behavior is dependent on the
> implementation of the C compiler.  If you want to try to define and
> implement additional behavior that is not defined by the C standard,
> then I don't think I can be of much help because I don't normally use
> these operators, though I would note that in C++, the program
>
>   #include <iostream>
>   int
>   main (void)
>   {
>     unsigned char x = 255;
>     std::cerr << (x << 1) << std::endl;
>     return 0;
>   }
>
> prints 510, but I'm not sure that's a behavior we would want since
> other operations on intX types saturate.

I get your point, but that example is fraught with all kinds of compiler casts.  The (x << 1) 
is probably cast to a regular int first and then bit shifted.  Because the output is a number, the (x 
<< 1) is clearly treated as an int, i.e., printf("%d",).  Here is what I get with 
casting to a char:

 std::cerr << ((unsigned char)(x << 1)) << std::endl;

address@hidden sebald]$ ./shift
�

That is, a blank character.  If we again cast that back to an int so that the 
value is printed to the stream:

 std::cerr << ((int)((unsigned char)(x << 1))) << std::endl;

address@hidden sebald]$ ./shift
254

which is what we'd expect... but doesn't saturate.

What operations are you referring to that saturate?

Dan