Unexpected output with char

I tried running the code below and i got an unexpected output

Code:

---

#include<stdio.h>
 void main()
{
        char a='A';
        while(a)
        {
                printf("%d\n",a );
                a++;
        }
        printf("%d",a);
        getchar();
}

---

The code is supossed to give an infinite loop but instead it terminates with a=0


I tried running it with some casting like this

Code:

---

#include<stdio.h>
 void main()
{
        char a='A';
        while((int)a)
        {
                printf("%d\n",(int)a );
                (int)a++;
        }
        printf("%d",(int)a);
        getchar();
}

---

But the output was the same as before.
Any help on why the code has this unexpected behaviour???

Usually it's

Code:

---

int main(void)
{
    ....
    return 0;
}

---

Then if you run it like this, I suppose you will not get an infinite loop, but the values of the ascii table.

If you give

Code:

---

printf("%c\n",a );

---

you will see the actual characters been printed. With your code, you will see the code numbers of these characters.

Quote:

---

Originally Posted by std10093

you will see the actual characters been printed. With your code, you will see the code numbers of these characters.

---

Yes but the problem is that it prints characters with decimal value 65 till it reaches 128 then it goes immediately to -128 i dont know why it has this trend

Because in C/C++ integral values have a finite limit. For example a signed char can only hold numbers in the range of -128 to 127.

Jim

128??? I would say that it reaches 127, because of the ascii table. See, here for more ascii values.

About the negative values, click here.

EDIT: Sorry jim, I hadn't seen your answer. :)

Thanks guys that rely helped

It's because char is a signed type (Two's complement - Wikipedia, the free encyclopedia), represented by a byte (8 bits). The top bit represents the sign, so the highest positive value that can be stored is 0111 1111 (127). Adding 1 to that gives 1000 0000 which in two's complement is the most negative number, -128. 1000 0001 is -127. And so on up to -1, which is 1111 1111. Adding 1 to this overflows, and gives 0000 0000, and terminates the loop.

An unsigned char would go from 65 to 256 then wrap to 0. If you try to treat values above 127 as characters, the result you get will vary. There's no single definition of how these characters are treated, asciitable.com offers one possible such interpretation.

It's worth noting that signed integer overflow in C is undefined behaviour. The reason this signed char arithmetic isn't is because of the integer promotion rules -- the code must behave as if both 'a' and the addition of '1' were cast to int and then truncated. So your casts just make explicit exactly what would happen under the hood. the underlying type is still char.
If you changed the type of a to an int, it *would* be undefined behaviour. Unsigned int, it wouldn't. It'd never be an infinite loop. If you involved a bignum library, it would grow until it ran out of memory. At some point it'd become effectively infinite, but... not actually infinite. while(1) is infinite.

Quote:

---

Originally Posted by smokeyangel

It's because char is a signed type ([url=http://en.wikipedia.org/wiki/Two%27s_complement]

---

Just to be precise, the OP's char type is twos complement. In general, overflow of a char (e.g. incrementing a char with value CHAR_MAX) has undefined behaviour - even with type promotion and demotion in the process, it is the storing a value in a char that is the problem.

Admittedly, (signed) char as a two's complement type is a pretty common feature these days. But it is still not required.