2

Apparently there are architectures that don't have 8-bit bytes.

It would seem that such architectures would preclude the existence of an int8_t (defined in stdint.h) type since C, from my understanding, cannot create datatypes smaller than a CHAR_BIT.

That said, the IEEE stdint.h def seems to require that such a type exist (along with others), only allowing for the 64-bit to not exist on architectures that do not support it.

Am I missing something?

Community
  • 1
  • 1
Dan
  • 3,246
  • 1
  • 32
  • 52
  • is there such an architecture still in existence? i doubt systems before 8080 or some rare doesnt support 8bit as a byte. But havent seen, read about such system lately – Kinjal Patel Mar 11 '13 at 10:32
  • Yep. I'm working on an architecture with a 16-bit char and a int8_t exists (and doesn't overflow / wrap the way you'd expect it to). – Vicky Mar 11 '13 at 11:40

2 Answers2

4

EDIT: As @JasonD points out in the comments below, the linked page states at the end;

As a consequence of adding int8_t, the following are true:

  • A byte is exactly 8 bits.

  • {CHAR_BIT} has the value 8, {SCHAR_MAX} has the value 127, {SCHAR_MIN} has the value -128, and {UCHAR_MAX} has the value 255.

In other words, the linked IEEE page does not apply to architectures with other byte lengths than 8. This is in line with POSIX which requires 8 bit char.

-- Before edit --

The explanation is in a note on the page you linked to;

The "width" of an integer type is the number of bits used to store its value in a pure binary system; the actual type may use more bits than that (for example, a 28-bit type could be stored in 32 bits of actual storage)

Joachim Isaksson
  • 176,943
  • 25
  • 281
  • 294
  • I can't believe I missed that! *facepalm* Thanks! – Dan Mar 11 '13 at 10:28
  • I do not think this is correct - the intN_t types are specified as being *exact* width types, with no padding, etc. – JasonD Mar 11 '13 at 10:31
  • @JasonD You may be correct, but the linked page (that extends the C standard) is slightly fuzzy about the length requirements for the _exact_ types. It _requires_ that uint8_t exists with width 8, but does not seem to require that it be stored in exactly 8 bits, just that it has the correct range. On the other hand, [C99](http://web.archive.org/web/20050207010641/http://dev.unicals.com/papers/c99-draft.html#7.18) declares all exact length types as entirely optional, only requiring some `least` and `fast` types. – Joachim Isaksson Mar 11 '13 at 10:49
  • However it states this seperately to the definition of int8_t, and moreover it states that a consequence of defining int8_t is that a byte is necessarily then strictly defined as 8-bits. So it is mututally exclusive with having a non 8-bit byte, the presence of which was a prerequisite for the question... :) – JasonD Mar 11 '13 at 11:10
1

Just because an architecture doesn't handle 8-bit bytes natively, doesn't preclude an exact 8-bit integral type. The arithmetic could be handled using shifts and masks of wider registers to 'emulate' 8-bit arithmetic.

Brett Hale
  • 21,653
  • 2
  • 61
  • 90
  • That would be true if you were coding in assembly. However, I don't believe that C supports types with a bitsize below a byte (someone correct me if I'm wrong). – Dan Mar 11 '13 at 10:35
  • 1
    Compilers do this all the time - implementing 8-bit 'char' or 16-bit 'short' on 32-bit RISC with no native 8-bit byte (R/W) support. – Brett Hale Mar 11 '13 at 10:37
  • Right. But registers exist with those exact sizes, whereas an 8-bit register would not exist on an architecture with 9-bit bytes. I don't know nearly enough about the C implementation to tell you you're wrong, but I swear I've read documentation somewhere that C will not support types below a byte in size. I'm happy to be proven wrong though. – Dan Mar 11 '13 at 10:44
  • C has bitfields; `int x:3;` is 3 bits on every machine. And thus there's also an eight bit variable available, even though it wouldn't match the native size of anything. – Aki Suihkonen Mar 11 '13 at 11:03