g ++ / gcc中char的签名及其历史

Question

First let me start off by saying that I know char , signed char and unsigned char are different types in C++. From a quick reading of the standard, it also appears that whether char is signed is implementation-defined. And to make things just a little more fun, it appears g++ decides whether a char is signed on a per-platform basis!

So anyway with that background, let me introduce a bug I've run into using this toy program:

#include <stdio.h>

int main(int argc, char* argv[])
{
    char array[512];
    int i;
    char* aptr = array + 256;

    for(i=0; i != 512; i++) {
        array[i] = 0;
    }

    aptr[0] = 0xFF;
    aptr[-1] = -1;
    aptr[0xFF] = 1;
    printf("%d\n", aptr[aptr[0]]);
    printf("%d\n", aptr[(unsigned char)aptr[0]]);

    return 0;
}

The intended-behavior is that both calls to printf should output 1. Of course, what happens on gcc and g++ 4.6.3 running on linux/x86_64 is that the first printf outputs -1 while the second outputs 1. This is consistent with chars being signed and g++ interpreting the negative array index of -1 (which is technically undefined behavior) sensibly.

The bug seems easy enough to fix, I just need to cast the char to unsigned like shown above. What I want to know is whether this code was ever expected to work correctly on an x86 or x86_64 machines using gcc/g++ ? It appears this may work as intended on ARM platform where apparently chars are unsigned, but I would like know whether this code has always been buggy on x86 machines using g++ ?

Answer 1

I see no undefined behavior in your program. Negative array indices are not necessarily invalid, as long as the result of adding the index to the prefix refers to a valid memory location. (A negative array index is invalid (ie, has undefined behavior) if the prefix is the name of an array object or a pointer to the 0th element of an array object, but that's not the case here.)

In this case, aptr points to element 256 of a 512-element array, so the valid indices go from -256 to +255 (+256 yields a valid address just past the end of the array, but it can't be dereferenced). Assuming CHAR_BIT==8 , any of signed char , unsigned char , or plain char has a range that's a subset of the array's valid index range.

If plain char is signed, then this:

aptr[0] = 0xFF;

will implicitly convert the int value 0xFF ( 255 ) to char , and the result of that conversion is implementation-defined -- but it will be within the range of plain char , and it will almost certainly be -1 . If plain char is unsigned, then it will assign the value 255 to aptr[0] . So the behavior of the code depends on the signedness of plain char (and possibly on the implementation-defined result of a conversion of an out-of-range value to a signed type), but there is no undefined behavior.

(Converting an out-of-range value to a signed type may also, starting with C99, raise an implementation-defined signal, but I know of no implementation that actually does that. Raising a signal on a conversion of 0xFF to char would probably break existing code, so compiler writers are highly motivated not to do that.)

Answer 2

The type of an array has nothing to do with the indexes (except for underlying memory access).

For example:

signed int a[25];
unsigned int b[25];

int value = a[-1];
unsigned int u_value = b[-5];

The indexing formula for both cases is:

memory_address = starting_address_of_array
               + index * sizeof(array_type);

As far as char goes, it's size is 1 regardless (by definition of the language specifications).

The usage of char in arithmetic expressions may depend on whether it is signed or unsigned.

Answer 3

The intended-behavior is that both calls to printf should output 1

Are you sure?

The rvalue of aptr[0] is a signed char and is -1, which is again used to index in to aptr[] and thus what you get is -1 for the first printf().

The same goes for the second printf but there, using a type cast you ensure that it is interpreted as an unsigned char, thus you end up with 255, and using it to index in to aptr[] you get 1 from the second printf().

I believe your assumption about the expected behavior is incorrect.

Edit 1:

It appears this may work as intended on ARM platform where apparently chars are unsigned, but I would like know whether this code has always been buggy on x86 machines using g++?

Based on this statement it seems that you know that char on x86 is signed (as against what some people assume what you assumed). As such the explanation that I provided should be good ie considering char as signed char on x86.

Edit 2:

Using a negative array index is perfectly fine as long as the pointer operand is to an interior element: stackoverflow.com/questions/3473675/negative-array-indexes-in-c – ecatmur

This is one of the comments to the question by @ecatmur. Which clarifies that a negative index is fine as against what some people think.

Answer 4

Your printf statements are the same as:

printf("%d\n", aptr[(char)255]);
printf("%d\n", aptr[(unsigned char)(char)255]);

And thus obviously depends on the platform's behavior for these conversions.

What I want to know is whether this code was ever expected to work correctly on an x86 or x86_64 machines using gcc/g++?

Taking 'correctly' to mean the behavior you describe, no, this should never have been expected to behave that way on a platform where char is signed.

When char is signed (and cannot represent 255) you get a value that is implementation defined and within the representable range. For an 8-bit, two's-complement representation that means you get some value in the range [-128, 127]. That means that the only possible outputs for:

printf("%d\n", aptr[(char)255]);

are "0" and "-1" (ignoring cases where printf fails). The common implementation defined conversion results in printing "-1".

---

The code is well defined but not portable between implementations that define different char signedness. Writing portable code includes not depending on char being signed or unsigned, which in turn means you should only use char values as array indices if the indices are limited to the range [0, 127].