3 ms·

Well, it's not lost in C itself. But in the practice of modern C programming, it's often sacrificed in favor of using integers of exact sizes (uintN_t), and man

Well, it's not lost in C itself. But in the practice of modern C programming, it's often sacrificed in favor of using integers of exact sizes (uintN_t), and many programs perform bitwise operation by assuming an exact size of integer. By C99, they are guaranteed to have the same number N of bits across all implementations, and they are included only if the implementation supports it. So the programs using them is standard C, but not 100% portable, there is no requirement in C to implement exact-width integers. Although modification of most programs shouldn't be difficult (there is uint_leastN_t), also, C compilers can be modified to treat extra bits as if they don't exist to allow existing programs to work again.

pjc50 7y ago
This is the other way round though; code using "int" is a disaster for portability, because you don't know what you're actually getting. So people use uintN_t to get something specific which behaves the same way on different platforms - i.e. portable. You can always #define or typedef uintN_t to a machine type. You can't re-typedef int. You can #define it, but people will hate you.
- burfog 7y ago
  I'm surprised that it isn't normal to provide a pragma for that. Something like this: #pragma push intsizes 1 2 2 4 0 #include <yimage.h> // old 16-bit header #pragma pop #pragma push intsizes 1 2 4 8 16 #include <servertypes.h> // uses 128-bit long long #pragma pop
  - pjc50 7y ago
    That makes it completely impossible while reading code to tell what the size of int is even on your system. And worsens header file include order problems.
- TwoBit 7y ago
  Even worse than int is long. So much old Unix code that was (incorrectly) using long to store pointer-sized types got broken on other 64 bit platforms.
  - deleted 7y ago
    [deleted]
  - TazeTSchnitzel 7y ago
    That was an interesting choice by Microsoft. I wonder if it broke 32-bit Windows code? https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_m...

pjc50 7y ago

This is the other way round though; code using "int" is a disaster for portability, because you don't know what you're actually getting. So people use uintN_t to get something specific which behaves the same way on different platforms - i.e. portable. You can always #define or typedef uintN_t to a machine type. You can't re-typedef int. You can #define it, but people will hate you.

burfog 7y ago
I'm surprised that it isn't normal to provide a pragma for that. Something like this: #pragma push intsizes 1 2 2 4 0 #include <yimage.h> // old 16-bit header #pragma pop #pragma push intsizes 1 2 4 8 16 #include <servertypes.h> // uses 128-bit long long #pragma pop
- pjc50 7y ago
  That makes it completely impossible while reading code to tell what the size of int is even on your system. And worsens header file include order problems.
TwoBit 7y ago
Even worse than int is long. So much old Unix code that was (incorrectly) using long to store pointer-sized types got broken on other 64 bit platforms.
- deleted 7y ago
  [deleted]
- TazeTSchnitzel 7y ago
  That was an interesting choice by Microsoft. I wonder if it broke 32-bit Windows code? https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_m...