1

7.20.1.1p3 mentions that exact-width integers ({u,}int{8,16,32,64}_t) are optional.

How will it practically limit the portability of my software if I use them?

(I'm particularly interested in supporting machines running Linux, Windows, or Mac OS.)

Petr Skocik
  • 58,047
  • 6
  • 95
  • 142
  • 1
    Unless you want to support old [big iron](https://en.wikipedia.org/wiki/Mainframe_computer) systems or ["mini computers"](https://en.wikipedia.org/wiki/Minicomputer) (like VAX, PDP, old IBM mainframes etc.), or perhaps special purpose [ASIC's](https://en.wikipedia.org/wiki/Application-specific_integrated_circuit) or [DSP's](https://en.wikipedia.org/wiki/Digital_signal_processor) then you will never really come in contact with a computer with "odd" word lengths. – Some programmer dude May 08 '18 at 11:38
  • 1
    I have not seen any modern compiler which does not support them. The modern one - less than 10 years old. Maybe if you plan to port it to the Cray or Unisys machines it can cause the problem. There are also (nowadays obsolete) DSP processors which do not support 8 bis data. – 0___________ May 08 '18 at 11:38
  • 1
    I am not aware of any machines running Linux, Windows or Mac OS that do not support these exact-width types. – Ian Abbott May 08 '18 at 12:39
  • It is certainly possible to not support 8 bit, or 16 bit, natively. 10 years ago we thought 8 bit characters were on the way out, but then utf8. There is very little practical benefit for a 64-bit processor to support 16 bit arithmetic. If you wanted to be safe, you could use the int_leastN_t forms. It is a pity the standards folk decided to name them this way round. – Gem Taylor May 08 '18 at 12:43
  • @GemTaylor: Most modern ISAs *don't* support 8 or 16-bit add/sub/mul. But C doesn't let you do operations at that width, anyway. The default integer promotion rules promote narrow operands to `int` (yes signed `int` even for `uint16_t * uint16_t`), and it's only in assigning the result to a `uint16_t` variable that you convert back down to 16-bit. All CPUs can do that with at worst an `and` instruction. All CPUs (except DEC Alpha and some ancient stuff) have byte and halfword loads/stores, too. [Can modern x86 hardware not store a single byte to memory?](//stackoverflow.com/q/46721075). – Peter Cordes May 09 '18 at 23:28
  • 1
    @GemTaylor: Multiplying two `uint16_t` variables on a machine with 32-bit `int` is a nasty corner case: signed overflow UB is possible! – Peter Cordes May 09 '18 at 23:30
  • @PeterCordes My point really was that it would be quite easy to imagine some (perhaps embedded) c compiler not supporting one of byte or short, for the reasons given, so not supporting these exact types. As you say, natively the processor may actually be forced to run quite inefficiently to actually support them, and I might not want that code on my system. As far as promotion to integer in order to perform operations, the compiler has to appear to do that and produce the correct result, but can optimise back down if the destination is small. – Gem Taylor May 10 '18 at 09:30

2 Answers2

2

As a very good rule of thumb, the exact width integers are fully supported by any machine with a CPU using 2's complement signed types.

You'll do well to find an exception. Some mainframes and cash registers might use 1's complement and the even rarer signed magnitude scheme. You might find it difficult to get your code running on such machines, but then, would you want it to?

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • From reading POSIX (e.g. hton{s,l} are defined in terms of uint16_t and uint32_t) it appears I can pretty much count {u,s}{8,16,32} on a POSIX platform and from https://en.wikipedia.org/wiki/Word_(computer_architecture) it appears I can pretty much count on {u,s}{8,16,32} on platforms made since the 90's (included). 64 bit types seem to be slightly problematic, though. However while not requiring uin64_t, the C standard does require uint_least64_t, so if I were to assume >= C99 support, I could at least count on something at least as large as 64 bits, which might come in handy for my use case – Petr Skocik May 18 '18 at 13:46
2

So what I found out:

and from https://en.wikipedia.org/wiki/Word_(computer_architecture) it seems one can pretty much count on hardware support for 8-bit, 16-bit, and 32-bit integers (but not necessarily 64-bit integers) on machines made since about 1978.

Petr Skocik
  • 58,047
  • 6
  • 95
  • 142
  • 1
    All mainstream 32-bit CPUs you might find in a real notebook / laptop / desktop / server computer have some kind of add-with-carry so they can do 64-bit add/sub at least reasonably efficiently (2 or 3 instructions). Wide multiply and even shift can be slower. **[C99 requires `long long` (which must be at least 64 bit)](https://stackoverflow.com/q/2127473)**, so it's extremely likely that `int64_t` and `uint64_t` are available on any C99 implementation on a computer with 8-bit bytes and multiple-of-8 / power-of-2 register widths (i.e. every normal CPU architecture). – Peter Cordes May 18 '18 at 21:19