28

In c++, specifically the cstdint header file, there are types for 8-bit integers which turn out to be of the char data type with a typedef. Could anyone suggest an actual 8-bit integer type?

tej-kweku
  • 393
  • 1
  • 3
  • 8
  • http://en.cppreference.com/w/cpp/types/integer – Jonathan Potter Feb 06 '16 at 20:43
  • 6
    As I understand it, `int8_t` is guaranteed to be an 8-bit integer, if it is defined at all. The fact that your implementation typedef's it as `char` (or maybe `signed char`) implies that your implementation's `char` is in fact 8 bits. Note that `char` and its relatives are always integer types in C and C++; this differs from some other languages that don't treat characters as arithmetic types. – Nate Eldredge Feb 06 '16 at 20:48
  • 1
    In the more common implementations, `char` is 8 bits. If it isn't 8 bits, there won't be a `std::int8_t`. – chris Feb 06 '16 at 20:51
  • 4
    Think of it like this: `char` is string character type, and should not be used for anything else. `unsigned char` and `signed char` are used as arithmetic types and are not useful for string characters. – StellarVortex Feb 06 '16 at 21:35

1 Answers1

33

Yes, you are right. int8_t and uint8_t are typedef to char on platforms where 1 byte is 8 bits. On platforms where it is not, appropriate definition will be given.

Following answer is based on assumption that char is 8 bits

char holds 1 byte, which may be signed or unsigned based on implementation.

So int8_t is signed char and uint8_t is unsigned char, but this will be safe to use int8_t/uint8_t as actual 8-bit integer without relying too much on the implementation.

For a implementer's point of view, typedeffing where char is 8 bits makes sense.

Having seen all this, It is safe to use int8_t or uint8_t as real 8 bit integer.

dlmeetei
  • 9,905
  • 3
  • 31
  • 38
  • 1
    Note that `int8_t` may not be a typedef to `char` on platforms in which `char` is less than 8 bits. – vsoftco Feb 06 '16 at 21:03
  • My belief is that `char` is 1 byte. Is it not? May be I need to reconfirm myself :) now – dlmeetei Feb 06 '16 at 21:05
  • `char` is 1 byte indeed, but 1 byte is not always 8 bits, see e.g. [this](http://stackoverflow.com/questions/2098149/what-platforms-have-something-other-than-8-bit-char). Although my belief is that `int8_t` is not defined for platforms in which a byte is not 8 bits. – vsoftco Feb 06 '16 at 21:06
  • Thanks, Updating accordingly. Learn something new today. That's why SO is great. – dlmeetei Feb 06 '16 at 21:09
  • 2
    No, they are not `typedef` to `char`. First, the `char` type is compiler dependent and can be `unsigned`, `signed` or `char`. A `int8_t` is a `signed` quantity and `uint8_t` is an unsigned quantity. They cannot be mapped to the same type. The only guarantee is that `int8_t` is a signed integer of 8-bits and `uint8_t` is an **unsigned** integer that is 8-bits wide. – Thomas Matthews Feb 06 '16 at 21:12
  • @ThomasMatthews I have mentioned that in the answer. May be my wording is not clear enough. Can you Add the appropriate one. Not a native speaker. I think char be either `signed` or `unsigned`, but not `char`. – dlmeetei Feb 06 '16 at 21:17
  • 1
    @vsoftco `char` has to be a minimum of 8 bits. It is even called out at the end of the link you provided. – NathanOliver Feb 06 '16 at 21:17
  • @NathanOliver Sorry, cannot find where. Can you point out the quote/standard? There is something about *18.2.2*, but didn't find anything in the C++ standard about `char` there. – vsoftco Feb 06 '16 at 21:22
  • 1
    I just want to throw in that the POSIX specification clearly demands that `CHAR_BIT == 8`, so for any evironment that is POSIX compliant, or has a legacy that was so, then `char` will be 8 bits. So for 99% of what typical (as in: not embedded firmware, DSP and such) programs are going to run in an environment where char is 8 bits. – datenwolf Feb 06 '16 at 21:23
  • 2
    "Appropriate definition will be given" should read "the types will not exist" – M.M Feb 06 '16 at 21:25
  • 1
    @vsoftco — **[intro.memory]** /1: _A byte is at least large enough to contain [...] **eight-bit** code units_ – Revolver_Ocelot Feb 06 '16 at 21:25
  • @NathanOliver I think there is something in the C standard *5.2.4.2.1*, which C++ 18.2.2 quotes. – vsoftco Feb 06 '16 at 21:26
  • @Revolver_Ocelot Perfect, thanks! Frankly I didn't know this. – vsoftco Feb 06 '16 at 21:26
  • 1
    @vsoftco look up the specification for limits.h, it will say that `UCHAR_MAX` must be at least `255` (from which we can deduce that it must be at least 8 bits) – M.M Feb 06 '16 at 21:26
  • 1
    @M.M I also found [*5.2.4.2.1* (pg. 22)](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf) which mandates `CHAR_BIT` (*number of bits for smallest object that is not a bit-field (**byte**)*) to be at least 8. This part of the C standard is being invoked by the C++ standard in *18.2.2*. – vsoftco Feb 06 '16 at 21:28
  • The int8_t and uint8_t types for gcc version 4.9.2, adsurdly, store numbers as char type and are integers only when either is in a mathematical expression – tej-kweku Feb 08 '16 at 14:49
  • @tej-kweku: I'm pretty sure that's exactly what `int8_t` and `uint8_t` are for, as specified by the C++ spec. – Mooing Duck Aug 09 '17 at 16:25
  • It is safe to use them indeed, but not if you want to print them as integers, they will be printed as `char`s, with all their usual rules. If you want to print them as integers cast them to an integer type when you do the printing. – KeyC0de Sep 30 '19 at 14:52