meaning of "1u"

G

godfather2

this should be an easy one ... what is the meaning of "1u", for instance:

#define DUMMY (1U<<31)

as opposed to just:

#define DUMMY (1<<31)
 
M

Mark A. Odell

(e-mail address removed) (godfather2) wrote in

this should be an easy one ... what is the meaning of "1u", for
instance:

#define DUMMY (1U<<31)

as opposed to just:

#define DUMMY (1<<31)

The former forces C to promote 31 to an unsigned int to match the unsigned
int 1U. This means that the resulting expression will have a type of
unsigned int (or unsigned long depending upon the platform) instead of the
signed alternative which one may not want.
 
B

Ben Pfaff

Mark A. Odell said:
(e-mail address removed) (godfather2) wrote in



The former forces C to promote 31 to an unsigned int to match the unsigned
int 1U. This means that the resulting expression will have a type of
unsigned int (or unsigned long depending upon the platform) instead of the
signed alternative which one may not want.

No, the expression will have a type of `unsigned int' regardless
of the platform. The value 1 always fits in an unsigned. On the
other hand, if the platform's unsigned ints are less than 32 bits
wide, then 1U<<31 is undefined.
 
C

Carsten Hansen

godfather2 said:
this should be an easy one ... what is the meaning of "1u", for instance:

#define DUMMY (1U<<31)

as opposed to just:

#define DUMMY (1<<31)

On a platform with 32-bit int's, the former is an unsigned int (0x80000000),
the latter is an int (-2147483648).
Same bit pattern.

The way I read the C99 Standard, the latter will result in undefined
behavior.
"The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
are filled with
zeros. If E1 has an unsigned type, the value of the result is E1 * (2**E2),
reduced modulo
one more than the maximum value representable in the result type. If E1 has
a signed
type and nonnegative value, and E1 * (2**E2) is representable in the result
type, then that is
the resulting value; otherwise, the behavior is undefined."


Carsten
 
D

Derk Gwen

(e-mail address removed) (godfather2) wrote:
# this should be an easy one ... what is the meaning of "1u", for instance:
#
# #define DUMMY (1U<<31)
#
# as opposed to just:
#
# #define DUMMY (1<<31)

Makes it an unsigned integer instead of signed. With 32 bit ints, it makes no
difference that I know of. However if the number shifted is large enough that
you would shift bits out of the left end, it would still not make a difference
on a twos complement machine, with zeros moved into the right end.

However on a ones complement machine signed left shifts are actually left rotates,
so that anything shifted out of the end reappears on the right end, while unsigned
left shifts move zeros into the right end.
 
A

Alex

No, the expression will have a type of `unsigned int' regardless
of the platform. The value 1 always fits in an unsigned. On the
other hand, if the platform's unsigned ints are less than 32 bits
wide, then 1U<<31 is undefined.

Is this really undefined? It is a silly thing to do, but I would
expect a consistent outcome (zero).

Alex
 
H

Hallvard B Furuseth

Alex said:
Is this really undefined?

Yes. There are processors that don't handle such shifts, so ANSI 3.3.7
says:

If the value of the right operand is negative or is greater than or
equal to the width in bits of the promoted left operand, the behavior
is undefined.
 
K

Keith Thompson

this should be an easy one ... what is the meaning of "1u", for instance:

#define DUMMY (1U<<31)

as opposed to just:

#define DUMMY (1<<31)

A suffix of either 'u' or 'U' on an integer literal means that the
literal is of type unsigned int.

BTW, you asked about "1u", but your example uses "1U". They happen to
mean the same thing, but this is one of the few cases where C is
case-insensitive. In most other contexts, 'u' and 'U' are distinct.
 
B

Ben Pfaff

Keith Thompson said:
A suffix of either 'u' or 'U' on an integer literal means that the
literal is of type unsigned int.

If such an integer literal is too big for unsigned int, it will
be type unsigned long int, or even unsigned long long int if
necessary. (I don't see where the standard says what happens to
an integer literal that won't fit into any integer type; perhaps
it is therefore undefined.)
 
K

Kevin Easton

Hallvard B Furuseth said:
Yes. There are processors that don't handle such shifts, so ANSI 3.3.7
says:

It's not so much "don't handle" as "handle differently". Some
processors do what Alex expected - they end up a with a result of 0.
Others only use the lower-order bits of the shift value, so shifting a
32 bit value by 32 bits is the same as shifting it by 0 bits.

- Kevin.
 
P

Peter Nilsson

Keith Thompson said:
A suffix of either 'u' or 'U' on an integer literal means that the
literal is of type unsigned int.
^^^
Since you're talking generally, it may be an unsigned long if the
value is too large to be stored in an unsigned int. [Or an unsigned
long long, or an extended unsigned integer type in C99.]
 
J

Jack Klein

(e-mail address removed) (godfather2) wrote in



The former forces C to promote 31 to an unsigned int to match the unsigned
int 1U. This means that the resulting expression will have a type of
unsigned int (or unsigned long depending upon the platform) instead of the
signed alternative which one may not want.

It does not force the integer constant 31 to be converted to unsigned
int. The integer promotions are performed on both operands, which in
this case forces no change at all. They do not need to be converted
to a common type, as they would be with many other binary operators,
and the standard does not require such a conversion.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
J

Jack Klein

(e-mail address removed) (godfather2) wrote:
# this should be an easy one ... what is the meaning of "1u", for instance:
#
# #define DUMMY (1U<<31)
#
# as opposed to just:
#
# #define DUMMY (1<<31)

Makes it an unsigned integer instead of signed. With 32 bit ints, it makes no
difference that I know of. However if the number shifted is large enough that
you would shift bits out of the left end, it would still not make a difference
on a twos complement machine, with zeros moved into the right end.

However on a ones complement machine signed left shifts are actually left rotates,
so that anything shifted out of the end reappears on the right end, while unsigned
left shifts move zeros into the right end.

Exactly where in the standard is this defined? Or, more likely, on
what hardware have you experienced this result, since it is most
surely not in the C standard?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
K

Kevin Bracey

In message <[email protected]>
Ben Pfaff said:
If such an integer literal is too big for unsigned int, it will
be type unsigned long int, or even unsigned long long int if
necessary. (I don't see where the standard says what happens to
an integer literal that won't fit into any integer type; perhaps
it is therefore undefined.)

In C99 at least, that's a constraint failure so it generates a diagnostic
(6.4.4: "The value of a constant shall be in the range of representable
values for its type".)
 
B

Ben Pfaff

Kevin Bracey said:
In message <[email protected]>


In C99 at least, that's a constraint failure so it generates a diagnostic
(6.4.4: "The value of a constant shall be in the range of representable
values for its type".)

It's not clear to me that such a problematic integer constant
*has* a type.
 
K

Kevin Bracey

In message <[email protected]>
Ben Pfaff said:
It's not clear to me that such a problematic integer constant
*has* a type.

I was hoping no-one would say that. I'll come back with:

6.4.4p3: "Each constant has a type, determined by its form and value,
as detailed later."

But it says later that "the type of an integer constant is the first of the
corresponding list in which its value can be represented.".

You could say that this last statement leaves a constant that doesn't fit
into any type in the list typeless. But if such a constant were typeless,
you'd be contradicting 6.4.4p3, and it would render constraint 6.4.4p2
meaningless, as it could never be invoked. I think you've got to infer intent
here.

This still leaves the question - what IS the type of an overlarge constant? I
would assume that it'd be the last type on the corresponding list, but the
standard doesn't say so.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,480
Members
44,900
Latest member
Nell636132

Latest Threads

Top