7 ms·

> Newer versions of the OS will almost certainly not behave this way, since glibc itself is marching down the road to having 64-bit time even on 32-bit machines

> Newer versions of the OS will almost certainly not behave this way, since glibc itself is marching down the road to having 64-bit time even on 32-bit machines. Did I miss something? How does this work?

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
augusto-moura 4y ago
What wouldn't work? 64 bit integers are supported on 32 bit machines by the compiler. The thing is that, AFAIK, it is a lot more inefficient when outputting the machine code. It does a lot more of instructions even for basic operations, like muls and divs. But from a C language perspective, everything should be transparent
- kevincox 4y ago
  Changing the size of a type wrecks havoc on ABI stability. glibc has attempted to change the size of things in the past with disastrous results. It sounds like changing this type would be very difficult. Not to mention code that does something like `int32_t time = gettime()`. (Although this code probably won't get much worse if that starts truncating)
  - irdc 4y ago
    Not if you at compile time redirect calls to e.g. time() to __time64()[1]. The musl libc does something similar[2], as do the Large File Support extensions for 64-bit filesizes[3]. 1. https://sourceware.org/glibc/wiki/Y2038ProofnessDesign https://sourceware.org/glibc/wiki/Y2038ProofnessDesign 2. https://musl.libc.org/time64.html https://musl.libc.org/time64.html 3. https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fFILE_005fOFFSET_005fBITS https://www.gnu.org/software/libc/manual/html_node/Feature-T...
    - kevincox 4y ago
      The point is that as soon as a library stores a time_t in an ABI-relevant structure it breaks a lot of stuff. So yes, for an application only linked to glibc it works fine. But when you have different libraries liked with different versions it quickly falls apart. For example see https://lwn.net/Articles/605607/ https://lwn.net/Articles/605607/
      - irdc 4y ago
        Indeed. And in cases like those, the application and any libraries it uses have to either agree on which time_t size to use, or perform the same rewriting as libc does. Getting libc on board is merely the first step. The same goes for _FILE_OFFSET_BITS for obvious reasons (though embedding an off_t is probably somewhat less common). Nobody said this would be easy. OpenBSD's "ABIs are for breaking"-approach resulted in them fixing this very problem almost 10 years ago: https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

augusto-moura 4y ago

What wouldn't work? 64 bit integers are supported on 32 bit machines by the compiler. The thing is that, AFAIK, it is a lot more inefficient when outputting the machine code. It does a lot more of instructions even for basic operations, like muls and divs. But from a C language perspective, everything should be transparent

kevincox 4y ago
Changing the size of a type wrecks havoc on ABI stability. glibc has attempted to change the size of things in the past with disastrous results. It sounds like changing this type would be very difficult. Not to mention code that does something like `int32_t time = gettime()`. (Although this code probably won't get much worse if that starts truncating)
- irdc 4y ago
  Not if you at compile time redirect calls to e.g. time() to __time64()[1]. The musl libc does something similar[2], as do the Large File Support extensions for 64-bit filesizes[3]. 1. https://sourceware.org/glibc/wiki/Y2038ProofnessDesign https://sourceware.org/glibc/wiki/Y2038ProofnessDesign 2. https://musl.libc.org/time64.html https://musl.libc.org/time64.html 3. https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fFILE_005fOFFSET_005fBITS https://www.gnu.org/software/libc/manual/html_node/Feature-T...
  - kevincox 4y ago
    The point is that as soon as a library stores a time_t in an ABI-relevant structure it breaks a lot of stuff. So yes, for an application only linked to glibc it works fine. But when you have different libraries liked with different versions it quickly falls apart. For example see https://lwn.net/Articles/605607/ https://lwn.net/Articles/605607/
    - irdc 4y ago
      Indeed. And in cases like those, the application and any libraries it uses have to either agree on which time_t size to use, or perform the same rewriting as libc does. Getting libc on board is merely the first step. The same goes for _FILE_OFFSET_BITS for obvious reasons (though embedding an off_t is probably somewhat less common). Nobody said this would be easy. OpenBSD's "ABIs are for breaking"-approach resulted in them fixing this very problem almost 10 years ago: https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2.