Unsigned and signed integers in C

Question

Possible Duplicate:
Unsigned long with negative value
Assigning negative numbers to an unsigned int?

#include<stdio.h>

int main()
{
    struct a 
    {
        unsigned int i:3;
        int c:3; 
    }s;
    s.i=5;
    s.c=5;

    printf("s.i=%d\n",s.i);
    printf("s.c=%u\n",s.c);
    unsigned int x = -1;
    printf(" x = %d", x);
    return 0;
}

This outputs:

s.i=5
s.c=4294967293
x=-1 

I am not clear about the output of "x" and "s.c"(s.c can store number of 3 bits only but in the output it is giving very large value)."x" is declared as unsigned so the bits stored in x are 1111111....... and the output of x should be a large value instead of -1. 1st printf() statement is giving the result as expected I am using devc++ compiler.

Answer 1

The output depends on the signedness of the format character, not the signedness of the declaration. Think about it: printf can't know whether x was declared int or unsigned int, since no type information is passed in C. So it prints based on how you told it to print. %d is signed, so you get a signed value. With s.c, it's an int so it's signed, but you printed it with %u so it is treated as unsigned.

As for s.i, it is unsigned, so 5 can fit in its 3 bits, so it is passed to printf as 5 without sign extending it, so %d (or %u) prints it as 5.

Answer 2

It seems there are two things going on that need to be understood:

• printf() conversion specifiers
• Integral conversions

And two more things that help make sense of your output:

• Argument promotion for variadic function arguments
• Two's complement representation

First, printf() is a variadic function. It doesn't know what the types of its arguments are (other than the format string), so you have to use conversion specifiers to tell it how to interpret the arguments. These arguments are subject to the "default argument promotions" such that your 3-bit bit fields are being promoted to ints.

You are using conversions specifiers (%d, %u, and %d) that do not match the signedness of your data, so you will get undefined behavior that depends on how your data is actually represented in memory.

Second, the C11 standard states:

6.3.1.3 Signed and unsigned integers

• When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged.

• Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.

• Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.

(As far as I can tell, the details relevant here have been true at least since C89.)

This tells us a couple things about your code:

• When you assign -1 to an unsigned int, UINT_MAX + 1 is added to it, giving UINT_MAX, or 4294967295 for 32-bit integers.

• When you try to assign 5 to a 3-bit signed bit field, the result is implementation-defined.

So you've got both undefined and implementation-defined behavior, but we can still try to make sense of your output, just for fun. I'm assuming 32-bit integers and two's complement representation.

Your system represents the 4294967295 stored in x as 11111111 11111111 11111111 11111111. When you told printf() that the argument you were passing it was signed, those same bits are interpreted as -1, which is the output you got.

For s.c, the implementation-defined behaviour you seem to have gotten is straightforward: the three bits 101representing 5 got stored as-is. That means that with the correct conversion specifier, printf() should show s.c as -3.

Here are the values you've assigned:

s.i = 101
s.c = 101
  x = 11111111 11111111 11111111 11111111

The 3-bit values are promoted to 32-bit by left-padding with 0 for the unsigned value and repeating the sign for the signed value:

s.i = 00000000 00000000 00000000 00000101
s.c = 11111111 11111111 11111111 11111101
  x = 11111111 11111111 11111111 11111111

Which, when interpreted as signed, unsigned, and signed integers gives:

s.i=5
s.c=4294967293
x=-1

The x=-1 suggests to me that you are in fact using a two's complement representation (which was a pretty safe bet, anyway), and the output for s.c suggests that your ints are 32 bits wide.