Re: [Ksummit-discuss] [CORE TOPIC] Dealing with 2038

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Tue, 2014-05-06 at 22:07 -0400, Theodore Ts'o wrote:
[...]
> One of the questions to evaluate this proposal is how many syscalls
> this would take.  And if we the goal is to "avoid a hard ABI break",
> then that also means doing something like the Large File Support hack
> (i.e., open64, read64, etc.) which is application visible.  Right?
> But the problem is unless you get all applications to use these
> non-standard, non-POSIX interfaces --- or you need to get them to use
> a magic #define, ala the LFS --- and good luck getting all
> applications to do make that change,

LFS is far from universally supported by applications, 17 years after it
was standardised.  In fact, many applications recently regressed due to
a broken test for LFS in autoconf <https://bugs.debian.org/742780>.  It
doesn't seem like a good example to follow.

> or to get distributions to modify
> their build scrpits to include that --- and then it's equivalent to a
> hard ABI break, since it means time_t changes size.
[...]

However this is done, almost every library that includes time_t in its
API will change ABI.  I say 'almost' because glibc will probably use
symbol versioning or mangling to maintain binary compatibility, but most
library maintainers won't go to that trouble.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]