Re: "undefined behavior"?

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>

(I'd like to a future standard require plain char to be unsigned,
but I don't know how likely that is.)

>
It seems unnecessary given that the upcoming C standard
is choosing to mandate two's complement for all signed
integer types.

>
It's less necessary, but I'd still like to see it.
>
These days, strings very commonly hold UTF-8 data.  The fact that bytes
whose values exceed 127 are negative is conceptually awkward, even if
everything happens to work.  It rarely if ever makes sense to treat a
character value as negative.

The combination of mandating two's complement and using a compiler
option like -funsigned-char (supported by both gcc and clang)
should be enough to do what you want.

(And of course signed char still exists,
or int8_t if you prefer 8 bits vs. CHAR_BIT bits.)

It makes me laugh when people use int8_t instead of signed char.
If CHAR_BIT isn't 8 then there won't be any int8_t.  And of
course we can always throw in a static assertion if it is felt
necessary to protect against implementations that don't have
8-bit chars.  (A static assertion also can verify that two's
complement is being used for signed char.)

A drawback is that it could break existing (non-portable) code that
assumes plain char is signed.

Exactly!  No reason to break the whole world when you can get
what you want just by using a compiler option.