7 ms·

Why portability will not come back? Also when the ability of working on non-multiple-of-8-bit integers was lost?

• gumby 7y ago
  AFAIK the last machine in widespread production that handled multi-length integers was the PDP-10/20 and its clones which essentially died around 1984. I say "around" because though DEC canceled the 20 line, some clones remained (that was Cisco's original business plan, for example)
  • ajuc 7y ago
    There was a series of Polish mineframes called Odra with 24bit integers which also died out in 80s essentially, but some of them were still used till 2010 in some specialized railway station software, and there was a short series of faster replacement processors for them made in late 80s-early 90s called SKOK. Of course they weren't "widespread" for most meanings of that word :)
    • burfog 7y ago
      You can get that experience today with the C compiler for the EZ80 chip. The short is 16-bit, and the long is 32-bit, so logically the int is 24-bit. You can use it as int24_t if you prefer. An EZ80 is used in some of the TI graphing calculators.
      • gumby 7y ago
        On the PDP-10/20 bytes could range from 1 to 63 bits wide.
• segfaultbuserr 7y ago
  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...