Thread: few doubts

Originally Posted by progmateur

why is it printing -121 ....
(after overflow at 127 (at FF for char assuming char uses 1 byte)
wont it start counting from 0?...(expecting 8 as answer)

because it doesn't start over at zero. char is a signed data type, which means it flips over to negative numbers when it overflows.

(why is it showing "false"?)

because sizeof() always returns a positive number.

Commenting on Q1:

In C, the type char is implementation defined if it is signed or unsigned. In C, it is implementation defined whether signed integers use two's complement (most common), one's complement, or sign-magnitude.

The following values from the <limits.h> file will tell you what the relevant information for your implementation is:

CHAR_BIT (paraphrase: number of bits in a char)
CHAR_MIN
CHAR_MAX

It seems that your implementation is using CHAR_BIT is 8, CHAR_MIN is -128, and CHAR_MAX is 127. That indicates that your implementation has char as a signed type using two's complement. This is a fairly common implementation.

Originally Posted by pheininger

In C, it is implementation defined whether signed integers use two's complement (most common), one's complement, or sign-magnitude.

without explaining what that means, or providing links to such explanations, you're likely to confuse the OP even more.

your implementation has char as a signed type using two's complement. This is a fairly common implementation.

it's actually the most common implementation, by a huge margin. so common, in fact, that you can usually assume that this is how it will be implemented. GCC, MSVC, and ICC all use that format. those three account for the vast majority of the market. the only time you're likely to encounter a different implementation is in obscure, special-purpose compilers for things like embedded systems. any PC, Linux, or Mac implementation is almost certainly going to exhibit the exact behavior you're seeing.

This is where limits.h is useful. It may seem like a pain but to be safe you have to check the limits. In your first example, do this:

Code:

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#define UB(...) do { printf("%s:%d: Undefined behaviour detected\n", __FILE__, __LINE__); exit(-1); } while(0)

int main(void) {
    char c = 125;
    if (c > CHAR_MAX - 10)
        UB();
    c += 10;
    printf("%d\n",c);
    
    return 0;
}

If you do lots of operations and want to guarantee that they are safe, then you could define some convenience macros

Code:

#define SAFE_ADD(VAR, AMOUNT) do { \
    if (VAR > CHAR_MAX - (AMOUNT)) \
        UB(); \
    VAR += (AMOUNT); \
} while(0)

Looks a bit ugly but then you can do something like this instead of the above check each time you operate on c

Code:

int amt;
scanf("%d", &amt);

char c = 125;
SAFE_ADD(c, amt);
printf("%d\n",c);

Originally Posted by Hodor

I think it's potentially worse not to mention this.

in this case, I disagree. it's obvious that the OP is a beginner, and bombarding him/her with information that is largely irrelevant to the task at hand is likely to confuse and discourage. the question was about why negative numbers come up when it overflows, and talking about implementation-defined behavior simply serves to muddy the water. it's completely unnecessary to worry about such things as a beginner.

Originally Posted by Elkvis

in this case, I disagree. it's obvious that the OP is a beginner, and bombarding him/her with information that is largely irrelevant to the task at hand is likely to confuse and discourage. the question was about why negative numbers come up when it overflows, and talking about implementation-defined behavior simply serves to muddy the water. it's completely unnecessary to worry about such things as a beginner.

I agree with Hodor on this one.

The OP's question suggested an expectation that a char would behave like an unsigned type (i.e. when overflow occurs, wrap at zero).

It is therefore appropriate both to point out that unadorned char may be either signed or unsigned, and that signed types do not behave in the expected way.

I've seen people say that before (without using the expression "implementation-defined"), only to trigger lots of comments - from either the OP or other forum members - like "with my compiler char is unsigned" or "my compiler has a signed char type, and overflow wraps", behaving as if the answer given is wrong. It then becomes necessary to fall back on the fact that the standard specifies that it is implementation-defined whether char is signed or unsigned, and also states that overflow of all signed native integral types (including a signed char) results in undefined behaviour.


I also disagree with your premise that, because three compilers dominate the market, that you should encourage beginners to assume particular behaviours that those compilers support. Code has a nasty habit of being reused even when its author does not intend it will be reused. Code written assuming some behaviour is well-defined that, in reality, is undefined causes no end of problems - because the bugs become VERY difficult to track down. And programmers who make such assumptions will probably miss out on significant job opportunities.