Implementation of fixed width integer types std::uint8_t and std::int8_t, C++

Question

I'm using the fixed width integer types std::int8_t and std::uint8_t which are included in C++ since C++11 (header <cstdint>). I use the gcc compiler for c++ programming (Linux, gcc --version 4.8.2).

On my machine the lines

#include <cstdint>
#include <type_traits>

//...

std::cout << std::is_same<std::uint8_t,unsigned char>::value << std::endl;
std::cout << std::is_same<std::int8_t,char>::value << std::endl;

give the output

1
0

In other words: std::uint8_t is implemented as unsigned char but std::int8_t is not implemented as char! I have no (reasonable) idea how it could be that std::int8_t is not implemented as char. Question: How can this result be interpreted?

`char` can be signed on some systems. Try comparing with `signed char` instead. — David G, Aug 10 '14 at 15:52
@ Matteo Italia + 0x499602D2: For signed char it gives 1, you are right. Is the difference between char and signed char only formal? — sperber, Aug 10 '14 at 15:55
@sperber: Why do you say that? Sounds like you think `char` is always signed, but that is not true. 1) It can be changed by compiler flags; 2) it's not even necessarily signed _by default_ on all systems. The signedness of `char` is entirely implementation-defined. — Lightness Races in Orbit, Aug 10 '14 at 15:57
@LightnessRacesinOrbit: Thanks, I didn't know it was implementation defined and indeed believed it was required to be signed. — sperber, Aug 10 '14 at 15:58

score 11 · Accepted Answer · edited May 23 '17 at 12:24

11

Probably they used signed char, which is sensible since compiler options (in gcc -fsigned-char and -funsigned-char) can change the signedness of plain char.

Notice that char, signed char and unsigned char are guaranteed to be distinct types, so it's normal that, even if on your compiler char is signed, it isn't considered the same as signed char.

Is the difference between char and signed char only formal?

No; char can be signed or unsigned depending on compiler and compiler options; signed char is always signed, no matter what.

(now, if you ask me, plain char should always be unsigned, but that's just my opinion)

edited May 23 '17 at 12:24

Community

1
1

answered Aug 10 '14 at 15:54

Matteo Italia

123,740
17
206
299

_"plain char should always be unsigned"_ What would be the point in that? That's what `unsigned char` is for... – Lightness Races in Orbit Aug 10 '14 at 15:59
@LightnessRacesinOrbit: because having a `signed` char by default (in most compilers) is only an annoyance - both when dealing with text *and* when dealing with "raw bytes" you *never* want to see signed values (= negative numbers for bytes >127); `unsigned char` is annoyingly long to type (especially when you are casting void pointers on the fly) and does not allow constructor-style casts. Also, in the rare cases when you actually want `signed char` you have to ask for it explicitly anyway. I don't know, the whole implementation-defined signedness seems to me gratuitous stupidity. – Matteo Italia Aug 10 '14 at 16:06
Considering that char is a number just like int is, sign should be given with the same rule as int: what about `int` `signed int` `unsigned int`? The sam shold be for `char`, `signed char` and `unsigned char`. But there are inconsistencies... – Emilio Garavaglia Aug 10 '14 at 16:09
@EmilioGaravaglia: IMO for practical usage `unsigned char` is needed way more often than `signed char`, but OK, that too would be better than the current state of affairs, at least in the rare occasions when you need a `signed char` you wouldn't have to specify `signed` explicitly. – Matteo Italia Aug 10 '14 at 16:10
@LightnessRacesinOrbit: yes, that was exactly my point: make evident a spec. inconsistency. – Emilio Garavaglia Aug 10 '14 at 16:14

score 4 · Answer 2 · edited May 23 '17 at 11:45

4

The type char is not required to be signed, even though on many systems it is.
Even when that is the case, it is distinct from the type signed char.

It is likely that int8_t is an alias for signed char.

edited May 23 '17 at 11:45

Community

1
1

answered Aug 10 '14 at 15:53

Lightness Races in Orbit

378,754
76
643
1,055

score 0 · Answer 3 · edited Apr 05 '19 at 18:31

char is not always signed, like many other inconsistencies that happen between various CPP implementations. I only realized this when I moved from MingGw on codeblocks to my simple phone compiler, which uses unsigned --- char.

Another inconsistency is void pointer and operator++. MingGw defines a one byte increment for that operator. But most other compilers won't compile incrementation of void pointers.

Then there is endianness.

Furthermore each compiler has its own preprocessor which uses different attributes and stuff.

These inconsistencies make programming in C and CPP quite difficult as undefined behaviour can cause crashes and logic errors that can be very hard to find.

A language like Java is very comfortable to use because Java compilers are made by one source, Oracle, and it is a write once kind of language.

However, it is not CPP fault that why inconsistencies are in the language. CPP and C stick to a low level approach, and each processor, each hardware is made differently. CPP takes these things into account.

Trying to write general code for the hardware is going to produce code that will be slower.

Implementation of fixed width integer types std::uint8_t and std::int8_t, C++

3 Answers3

Linked