Is it UB once it's an L-value?

[Old Wolf]

Do you even know that signed integer overflow is UB.

For instance:
signed char c=127;
++c; // undefined behavior (assuming that MAX_CHAR is 127).

(There is no such thing as MAX_CHAR, I guess you mean CHAR_MAX).

This is assignment of an out-of-range value, and is implementation-
defined. Integer overflow would be:

int m = INT_MAX;
++m;

When evaluating your ++c, c is promoted to integer before
applying the ++ operator. The integer 127 can be incremented
to 128 successfully. Then when 128 is reassigned to c, the
out-of-range assignment occurs.

 

[Alf P. Steinbach]

* Old Wolf:

(There is no such thing as MAX_CHAR, I guess you mean CHAR_MAX).

This is assignment of an out-of-range value, and is implementation-
defined. Integer overflow would be:

int m = INT_MAX;
++m;

When evaluating your ++c, c is promoted to integer before
applying the ++ operator. The integer 127 can be incremented
to 128 successfully. Then when 128 is reassigned to c, the
out-of-range assignment occurs.

++ is applied to lvalues. There's no such thing as promotion of
lvalues. However, the /result/ (after changing c), an rvalue, is promoted.

 

[Old Wolf]

* Old Wolf:

++ is applied to lvalues. There's no such thing as promotion of
lvalues. However, the /result/ (after changing c), an rvalue, is promoted.

Let me rephrase then:

A constraint of prefix-++ is that the operand is a modifiable lvalue.
The actual operation consists of performing an rvalue conversion
(which results in an int), adding 1 to it, and then assigning this
rvalue back to the original lvalue, which causes the out-of-range
assignment.

(See 5.3.2 and 5.17 for references).

 

[Alf P. Steinbach]

* Old Wolf:

Let me rephrase then:

A constraint of prefix-++ is that the operand is a modifiable lvalue.
The actual operation consists of performing an rvalue conversion
(which results in an int), adding 1 to it, and then assigning this
rvalue back to the original lvalue, which causes the out-of-range
assignment.

(See 5.3.2 and 5.17 for references).

I don't find anything about rvalue conversion there. But then, I fail
to see how, for a non-volatile c, your description could be effectively
different from just adding 1 to c, which is what the standard
proscribes. So I think that for a non-volatile c it's a legitimate
point of view, but the rvalue conversion is IMHO (humble because failing
to see ~X isn't seeing X) an unnecessary complication.

For a volatile c the situation is a little more complicated.

But also there I think (vaguely! ;-)) it's possible to express that
point of view so that it works.