Re: [avr-chat] Type promotion and shift operators

[Michael Hennebry]

On Wed, 2 Feb 2011, Rick Mann wrote:

> On Feb 2, 2011, at 12:39:12, Michael Hennebry wrote:

> > > No, I wasn't proposing that as the code I should write. I was trying to codify what you said. 
> > > You said, "the type of x<<y is now the type of x after the usual integer 
> > > promotions":
> >
> > C doesn't believe is doing arithmetic on chars or shorts.
> > Had x been a short it would have been promoted to int before the shift.
> > In principle, y could be promoted,
> > but it wouldn't affect the type of the result.
>
> Well, neither type is char or short. int is 16 bits and signed. I think the the 
> literal 1 gets type int. The problem I see is this: according to my K&R C book 
> (which you seem to be saying is out of date), the smaller type is promoted to a 
> larger type when the types on an operator are different. Which led me to believe 
> that the 1 (an implicit int) should be promoted to uint32_t. Now, I'm not 100% 
> clear, because they also differ in signdedness.

1 is an int, so the integer promotions I mentioned don't affect 1<<v.
The type of ((signed char)1)<<v would also
be int regardless of the type of v.

> But you're telling me a "quiet change" (to the language spec, I presume) means that for the 
> << operator, the resulting type is the type of the LHS. But you also said "after the usual 
> integer promotions," which I took to mean the original behavior of C, which is to promote the size 
> of the smaller type to something that will fit the larger type.

No. I referring to the fact that C does not
regard shorts and chars as arithmetic types.
If you try to do arithmetic on them,
C will promote them.

> So, if it first promotes, that means it does the equivalent of
>
>         ((long) 1) << v

As quoted by David A. Lyons, the integer promotions
will only change a type to int or to unsigned int.

> But if the result then has the type of the LHS (int), it then casts that result 
> to int, thereby throwing away bits. I don't know why they was considered to be 
> correct. If I were adding instead of shifting, it would work fine.
>
> So, it seems wrong to me, and it makes for unnecessarily verbose code, as well 
> as code that has to be more carefully considered when changing the type of the 
> result.

In C, left op rite will result in left and
rite being converted to the same type,
*unless* op is a shift operator.
The reason for the exception should be fairly obvious.
Methinks the sun will go out before we need a long shift count.
In principle, left<<rite subjects both left and rite to integer promotion,
but the promotion of rite will never change the value of the result.

--
Michael   address@hidden
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."