Would you like signs with those chars? [LWN.net]

Would you like signs with those chars?

Posted Oct 24, 2022 19:41 UTC (Mon) by mss (subscriber, #138799)
Parent article: Would you like signs with those chars?

That signed / unsigned char difference is a potent source of subtle bugs.

For example the following code:

char c = 0xff;
printf ("%x\n", c - 1);

will print fffffffe if char is signed but just (intuitively expected) fe if it is unsigned.

to post comments

Would you like signs with those chars?

Posted Oct 24, 2022 21:29 UTC (Mon) by mb (subscriber, #50428) [Link] (5 responses)

>will print fffffffe if char is signed but just (intuitively expected) fe if it is unsigned.

Well, char in case of signed is consistent with short (always signed).

short c = 0xffff;
printf ("%x\n", c - 1);

prints fffffffe.

Therefore, char = unsigned char actually is inconsistent.

Would you like signs with those chars?

Posted Oct 25, 2022 6:35 UTC (Tue) by eru (subscriber, #2753) [Link] (4 responses)

The difference with char and short is that people primarily expect char to contain a character (it's even in its name, and string literals are arrays of char), but shorts are used for numbers. This is why having char as a signed type is insane. Whoever has heard of a negative letter 'A'? Back in eighties when first learning C, and porting C programs from the usenet to my crummy PC/XT clone, I often tripped up because of this, as my language requires more than A-Z to write. It was a real pain.

Would you like signs with those chars?

Posted Oct 25, 2022 10:36 UTC (Tue) by geert (subscriber, #98403) [Link] (3 responses)

Don't forget all of this was introduced in the days of 7-bit ASCII[*], so a signed char was fine. In fact it also allows you to store a negative error code, without wasting precious memory on expanding beyond a single byte.
8-bit ASCII (e.g. ISO-8859-*) was only standardized in the eighties, which is about the same time as PowerPC and ARM saw the day of light, so making char default to unsigned may made sense for them (modulo the compatibility issues).

[*] EBCDIC is 8-bit, and seems to have an intentional division in characters with and without bit 7 (the "sign" bit) set.
https://en.wikipedia.org/wiki/EBCDIC#Code_page_layout

Would you like signs with those chars?

Posted Oct 25, 2022 13:15 UTC (Tue) by eru (subscriber, #2753) [Link] (1 responses)

8-bit character sets were not that new, although I agree they mostly post-date C. The Commodore micros since the 1970's used "PETSCII" with graphics characters in the upper half, and the IBM PC has since 1981 had its own character set with ASCII in the lower half, and a mixture of graphics and accented letters in upper (selection depending on the region).

Would you like signs with those chars?

Posted Oct 25, 2022 19:58 UTC (Tue) by khim (subscriber, #9252) [Link]

> 8-bit character sets were not that new, although I agree they mostly post-date C.

Note that bunch of these was in wide use way before C was a thing.

Would you like signs with those chars?

Posted Nov 4, 2022 20:07 UTC (Fri) by fest3er (guest, #60379) [Link]

This is why the DEC-10 was nice. Bytes could be defined from 1 to 36 bits in length. Granted, this could result in unused bits in words, but that's the price of flexibility. :)

Would you like signs with those chars?

Posted Oct 25, 2022 4:56 UTC (Tue) by SLi (subscriber, #53131) [Link] (4 responses)

Though in the signed case it might print or do anything else too (in standard C), since assigning an overflowing value to a signed integer is undefined behavior. Unless there is some exception for chars (C is quirky and I don't remember).

Would you like signs with those chars?

Posted Oct 25, 2022 7:06 UTC (Tue) by Villemoes (subscriber, #91911) [Link] (1 responses)

Let's be completely precise here. It is not undefined, it is "implementation-defined or an implementation-defined signal is raised".

C99, 6.5.16.1 Simple assignment

(2) In simple assignment (=), the value of the right operand is converted to the type of the
assignment expression and replaces the value stored in the object designated by the left
operand.

and that "converted to the type of" is covered in

6.3 Conversions, 6.3.1.3 Signed and unsigned integers:

(1) 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.
(2) 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.
(3) 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.

And in practice, any relevant compiler (at least when we're talking the linux kernel, but I'd be surprised if any non-academic compiler did otherwise) does as gcc:

* 'The result of, or the signal raised by, converting an integer to a
signed integer type when the value cannot be represented in an
object of that type (C90 6.2.1.2, C99 and C11 6.3.1.3).'

For conversion to a type of width N, the value is reduced modulo
2^N to be within range of the type; no signal is raised.

Would you like signs with those chars?

Posted Oct 25, 2022 9:31 UTC (Tue) by SLi (subscriber, #53131) [Link]

Ah, indeed; I forgot that there's a difference between conversions (which is implementation-defined) and general signed overflow, which is undefined. Thanks for pointing that out :)

I don't think it's only a matter of being "completely precise"; relying on implementation-defined behavior can be reasonable choice, relying on undefined behavior that a compiler vendor has not explicitly declare they define, to me, usually cannot. (I know Linus would disagree with me :D)

Allowing an implementation-defined signal seems a bit horrible here, though, but I think I understand where the committee was coming from...

Would you like signs with those chars?

Posted Oct 25, 2022 7:39 UTC (Tue) by matthias (subscriber, #94967) [Link] (1 responses)

In this case, there is no overflow. Subtracting 1 from 0xff is non-overflowing regardless of whether the type is signed or unsigned. If it is signed, the result is -2 (0xfe) And in both cases, the result is well within the bounds of an int. The difference is whether it gets sign-extended (signed char) or not (unsigned char).

Would you like signs with those chars?

Posted Oct 25, 2022 9:59 UTC (Tue) by SLi (subscriber, #53131) [Link]

True. I was thinking that the assigning 255 to a signed char part would be UB (like signed integer overflow), but as was pointed above, conversion when the number does not fit is merely implementation-defined.