[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Hennebry
Subject: Re: [avr-chat] Type promotion and shift operators
Date: Wed, 2 Feb 2011 17:48:03 -0600 (CST)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

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 

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 

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."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]