[std-proposals] signed char is not treated as char and unsigned char

[r***@gmail.com]

I noticed, that in several places in the standard, e.g in [basic.types],
char, unsigned char, or std::byte are mentioned separately (basically as
types that types that can alias anything else from my understanding).
There's no signed char in the list, despite it's a separate type.
What may be a reason for that?

[Thiago Macieira]

Post by r***@gmail.com
I noticed, that in several places in the standard, e.g in [basic.types],
char, unsigned char, or std::byte are mentioned separately (basically as
types that types that can alias anything else from my understanding).
There's no signed char in the list, despite it's a separate type.
What may be a reason for that?

Because it's signed. As a signed integer, there could be bit patterns that
don't form valid, unique values. For example, in one's complement, 0x00 and
0xFF are both zero
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[FrankHB1989]

圚 2018幎11月29日星期四 UTC+8䞊午6:21:21Thiago Macieira写道

Post by Thiago Macieira

Post by r***@gmail.com
I noticed, that in several places in the standard, e.g in [basic.types],
char, unsigned char, or std::byte are mentioned separately (basically as
types that types that can alias anything else from my understanding).
There's no signed char in the list, despite it's a separate type.
What may be a reason for that?

Because it's signed. As a signed integer, there could be bit patterns that
don't form valid, unique values. For example, in one's complement, 0x00 and
0xFF are both zero
This is the not the whole story. The exceptional case of strict aliasing

rule is applied char or unsigned char but not signed char in C++; however,
all of them are equal in C which also allows one's complement.

The special treatment is certainly an artifact. But it seems that the signed
char type itself is not a first-class citizen, but just a byte-width signed
integer type occasionally built-in, so the difference is intended.

And moreover... why on earth having signed char in the core language today?
Personally I'd happy to vote it deprecated since we have std::int8_least_t
and std::int8_t (albeit it is somewhat based on signed char in current
wording).

[Thiago Macieira]

Post by FrankHB1989
And moreover... why on earth having signed char in the core language today?

Sorry, but why not have a signed byte-sized integer?

In C, int8_t is not mandatory and int8_least_t could be actually be bigger
than a byte. C++ does not allow for machines with bytes less then 8 bits wide,
but I think C still does.

For that reason, removing or deprecating signed char is unlikely to ever
happen.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[FrankHB1989]

圚 2018幎11月29日星期四 UTC+8䞋午1:54:52Thiago Macieira写道

Post by FrankHB1989

Post by FrankHB1989
And moreover... why on earth having signed char in the core language

today?
Sorry, but why not have a signed byte-sized integer?
We should have it, like int*N*_t, likely with the additional guarantee of

mandatory. It just need not be built-in in the core language, as it has no
special meaning interested by other language features. All usefulness of
such a type has been addressed by more effective high-level abstractions
like *integral type* and *object type*. Being size of one byte does not
make it outstanding and worth special rules.

On the contrary, the meaning of "byte" itself is far more significant.
(Although it is still not special as real odd ones (e.g. void) in many
senses.) Historically the notion "byte" is defined by the so called
"character types" which has raised serious confusion. A sane design should
better get rid of such dependency (and better differentiate it with *octet*).
The significance of byte comes from the need of addressing data on memory.
For this purpose, the basic unit can be the byte or the word in the type
system. Theoretically the latter may be even better for clarity and
simplicity (to ease the design like alignment), but for realistic
portability, we use the former. Well even this is the fact, now std::byte
is still in the library rather than the core language. (And if we had decltype
40 years ago, we would probably define size_t in the library, as did
std::nullptr_t.)

Post by FrankHB1989
In C, int8_t is not mandatory and int8_least_t could be actually be bigger
than a byte. C++ does not allow for machines with bytes less then 8 bits wide,
but I think C still does.

This is the current wording living for historical reasons. Changing the
rules without effecting the conformance and available of existing
implementations is possible, even though no one bother to propose the
change - it is lack of motivation. But if the language *was *specialized
like that, it would be ... with less popular fundamental misconceptions
among its users, at least.

Post by FrankHB1989
For that reason, removing or deprecating signed char is unlikely to ever
happen.
Anyway, I agree with this conclusion.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[FrankHB1989]

圚 2018幎11月29日星期四 UTC+8䞋午3:29:24FrankHB1989写道

Post by FrankHB1989
圚 2018幎11月29日星期四 UTC+8䞋午1:54:52Thiago Macieira写道

Post by FrankHB1989

Post by FrankHB1989
And moreover... why on earth having signed char in the core language

today?
Sorry, but why not have a signed byte-sized integer?
... we would probably define size_t in the library ...

Oops, some words occasionally deleted ...

It should be "we would probably define more types other than *size_t* in
the library".

[Alberto Barbati]

Il giorno mercoledì 28 novembre 2018 23:21:21 UTC+1, Thiago Macieira ha

Post by Thiago Macieira
Because it's signed. As a signed integer, there could be bit patterns that
don't form valid, unique values. For example, in one's complement, 0x00 and
0xFF are both zero

Not in C++20, where signed integers are required to be represented in two's
complement. See http://wg21.link/p1236

[Thiago Macieira]

Il giorno mercoledì 28 novembre 2018 23:21:21 UTC+1, Thiago Macieira ha

Post by Thiago Macieira
Because it's signed. As a signed integer, there could be bit patterns that
don't form valid, unique values. For example, in one's complement, 0x00 and
0xFF are both zero

Not in C++20, where signed integers are required to be represented in two's
complement. See http://wg21.link/p1236

Sorry, but until C++20 is FDIS, it's not a guarantee. Is that paper accepted
into the draft standard already? Do we know that no national body will object
to this and force it out?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Alberto Barbati]

Il giorno venerdì 30 novembre 2018 17:58:02 UTC+1, Thiago Macieira ha

Post by Thiago Macieira

Post by Alberto Barbati
Il giorno mercoledì 28 novembre 2018 23:21:21 UTC+1, Thiago Macieira ha

Post by Thiago Macieira
Because it's signed. As a signed integer, there could be bit patterns

that

Post by Alberto Barbati

Post by Thiago Macieira
don't form valid, unique values. For example, in one's complement,

0x00

Post by Alberto Barbati

Post by Thiago Macieira
and
0xFF are both zero

Not in C++20, where signed integers are required to be represented in

two's

Post by Alberto Barbati
complement. See http://wg21.link/p1236

Sorry, but until C++20 is FDIS, it's not a guarantee.

That is correct.

Post by Thiago Macieira
Is that paper accepted into the draft standard already?

Yes, it was accepted in San Diego.

Do we know that no national body will object to this and force it out?
No, we don't. I can't estimate the chance of that happening, but historical
records suggests that it's very low.

[Jens Maurer]

Post by Thiago Macieira

Il giorno mercoledì 28 novembre 2018 23:21:21 UTC+1, Thiago Macieira ha

Post by Thiago Macieira
Because it's signed. As a signed integer, there could be bit patterns that
don't form valid, unique values. For example, in one's complement, 0x00 and
0xFF are both zero

Not in C++20, where signed integers are required to be represented in two's
complement. See http://wg21.link/p1236

Sorry, but until C++20 is FDIS, it's not a guarantee. Is that paper accepted
into the draft standard already?

Yes. The next revision of the Working Draft should be out in a couple
of days.

Post by Thiago Macieira
Do we know that no national body will object
to this and force it out?

We don't, but I'd consider the "force it out" outcome rather unlikely.

Jens

[Thiago Macieira]

Post by Jens Maurer

Post by Thiago Macieira
Do we know that no national body will object
to this and force it out?

We don't, but I'd consider the "force it out" outcome rather unlikely.

Thank you. I'll defer to your and Alberto's experience on this.

I asked because changing those very old compatibility requirements tend to
bring out people who think they might need it in the future or has some old
machine that still uses it. Just think of trigraphs.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center