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

Would you like signs with those chars?

Posted Oct 25, 2022 4:56 UTC (Tue) by SLi (subscriber, #53131)
In reply to: Would you like signs with those chars? by mss
Parent article: Would you like signs with those chars?

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).

to post comments

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.