4 ms·

The problem is not old binaries, it is old code that assumes an upper bound to the size of intmax_t.

by afiori 4y ago

teddyh 4y ago
I’m not sure what you mean. I agree that the problem is not the binaries, but I believe the problem to be the operating system. The source code may not have assumed a specific upper size limit on intmax_t, but the binaries were compiled in good faith to a specific machine architecture, which had a specific width on intmax_t, namely the largest integer type which that architecture could support. If then new CPU models come out with larger integer types, but the operating systems still runs that same binary straight up (without any emulation layer), this exposes the old binary to larger integer types, breaking the binary. The binary is not at fault, it’s the operating system which committed the sin of running the binary on what is effectively a different architecture without any considerations on what architecture the binary was actually compiled for.
- afiori 4y ago
  The OS could do this for old binaries but no for old source. A lot of FOSS code has baked in assumptions about the max size of intmax_t and the compiler and the OS cannot do much about broken logic.
  - teddyh 4y ago
    > A lot of FOSS code has baked in assumptions about the max size of intmax_t Well, that code is not, and was not ever, standards compliant.
    - shadowgovt 4y ago
      And it turns out that doesn't matter much in terms of adoption and popularity. After all, if predictable behavior in the future across all possible configurations were a high priority requirement for the tools people use to make computers do things, neither C nor C++ would have gotten off the ground. Instead, people don't memorize the entire standard. They write code that works on their machine, publish it, fix the bugs when people say it doesn't work on their machine, and maybe converge towards something that is standards compliant but, more likely, they converge towards something that works on the standard implementation on 90% of the operating systems available.
  - kazinator 4y ago
    > A lot of FOSS code has baked in assumptions about the max size of intmax_t Would you be able to name three examples?
    - afiori 4y ago
      I realize I used FOSS improperly, I had no reason to single it out; my comment reads like a critique of open source which was not my intention. My intention was to make a good case for old code being compiled today by third parties. But to my understanding intmax_t was introduced in C99, before widespread dominance of 64 bits platforms. So it would not be surprising that there exists code with lower assumptions about its size. But actually I made also another mistake, the major problem had little to do with faulty logic and more to do with dynamic linking [0] I will see myself out today. [0] https://thephd.dev/intmax_t-hell-c++-c https://thephd.dev/intmax_t-hell-c++-c

The problem is not old binaries, it is old code that assumes an upper bound to the size of intmax_t.

by afiori 4y ago

The problem is not old binaries, it is old code that assumes an upper bound to the size of intmax_t.

I’m not sure what you mean. I agree that the problem is not the binaries, but I believe the problem to be the operating system. The source code may not have assumed a specific upper size limit on intmax_t, but the binaries were compiled in good faith to a specific machine architecture, which had a specific width on intmax_t, namely the largest integer type which that architecture could support. If then new CPU models come out with larger integer types, but the operating systems still runs that same binary straight up (without any emulation layer), this exposes the old binary to larger integer types, breaking the binary. The binary is not at fault, it’s the operating system which committed the sin of running the binary on what is effectively a different architecture without any considerations on what architecture the binary was actually compiled for.

afiori 4y ago
The OS could do this for old binaries but no for old source. A lot of FOSS code has baked in assumptions about the max size of intmax_t and the compiler and the OS cannot do much about broken logic.
- teddyh 4y ago
  > A lot of FOSS code has baked in assumptions about the max size of intmax_t Well, that code is not, and was not ever, standards compliant.
  - shadowgovt 4y ago
    And it turns out that doesn't matter much in terms of adoption and popularity. After all, if predictable behavior in the future across all possible configurations were a high priority requirement for the tools people use to make computers do things, neither C nor C++ would have gotten off the ground. Instead, people don't memorize the entire standard. They write code that works on their machine, publish it, fix the bugs when people say it doesn't work on their machine, and maybe converge towards something that is standards compliant but, more likely, they converge towards something that works on the standard implementation on 90% of the operating systems available.
- kazinator 4y ago
  > A lot of FOSS code has baked in assumptions about the max size of intmax_t Would you be able to name three examples?
  - afiori 4y ago
    I realize I used FOSS improperly, I had no reason to single it out; my comment reads like a critique of open source which was not my intention. My intention was to make a good case for old code being compiled today by third parties. But to my understanding intmax_t was introduced in C99, before widespread dominance of 64 bits platforms. So it would not be surprising that there exists code with lower assumptions about its size. But actually I made also another mistake, the major problem had little to do with faulty logic and more to do with dynamic linking [0] I will see myself out today. [0] https://thephd.dev/intmax_t-hell-c++-c https://thephd.dev/intmax_t-hell-c++-c