meaning of "1u"

[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)

[Mark A. Odell]

df****@earthlink.net (godfather2) wrote in
news:d1**************************@posting.google.c om:

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.

--
- Mark ->
--

[Ben Pfaff]

"Mark A. Odell" <no****@embeddedfw.com> writes:

df****@earthlink.net (godfather2) wrote in
news:d1**************************@posting.google.c om:

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.

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.
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein

[Carsten Hansen]

"godfather2" <df****@earthlink.net> wrote in message
news:d1**************************@posting.google.c om...

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

[Derk Gwen]

df****@earthlink.net (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.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
OOOOOOOOOO! NAVY SEALS!

[Alex]

Ben Pfaff <bl*@cs.stanford.edu> wrote:

"Mark A. Odell" <no****@embeddedfw.com> writes:

df****@earthlink.net (godfather2) wrote in
news:d1**************************@posting.google.c om:

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

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

[Hallvard B Furuseth]

Alex wrote:

if the platform's unsigned ints are less than 32 bits
wide, then 1U<<31 is undefined.

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.

--
Hallvard

[Alex]

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:

Alex wrote:

if the platform's unsigned ints are less than 32 bits
wide, then 1U<<31 is undefined.

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.

Thanks.

[Keith Thompson]

df****@earthlink.net (godfather2) writes:

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.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Ben Pfaff]

Keith Thompson <ks*@cts.com> writes:

df****@earthlink.net (godfather2) writes:

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.

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.)
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Kevin Easton]

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:

Alex wrote:

if the platform's unsigned ints are less than 32 bits
wide, then 1U<<31 is undefined.

Is this really undefined?

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.

[Peter Nilsson]

Keith Thompson <ks*@cts.com> wrote in message news:<lz************@cts.com>...

df****@earthlink.net (godfather2) writes:

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.

^^^
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.]

--
Peter

[Jack Klein]

On 11 Sep 2003 14:46:58 GMT, "Mark A. Odell" <no****@embeddedfw.com>
wrote in comp.lang.c:

df****@earthlink.net (godfather2) wrote in
news:d1**************************@posting.google.c om:

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.

--
- Mark ->

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

[Jack Klein]

On Thu, 11 Sep 2003 19:04:34 -0000, Derk Gwen <de******@HotPOP.com>
wrote in comp.lang.c:

df****@earthlink.net (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

[Kevin Bracey]

In message <87************@pfaff.stanford.edu>
Ben Pfaff <bl*@cs.stanford.edu> wrote:

Keith Thompson <ks*@cts.com> writes:

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

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

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: [phone]
182-190 Newmarket Road Fax: [phone]
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/

[Ben Pfaff]

Kevin Bracey <ke**********@tematic.com> writes:

In message <87************@pfaff.stanford.edu>
Ben Pfaff <bl*@cs.stanford.edu> wrote:

Keith Thompson <ks*@cts.com> writes:

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

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.
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell

[Kevin Bracey]

In message <87************@pfaff.stanford.edu>
Ben Pfaff <bl*@cs.stanford.edu> wrote:

Kevin Bracey <ke**********@tematic.com> writes:

In message <87************@pfaff.stanford.edu>
Ben Pfaff <bl*@cs.stanford.edu> wrote:

(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.4p2: "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.

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.

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: [phone]
182-190 Newmarket Road Fax: [phone]
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/