[gentoo-dev] time64 ABI fix coming to upstream glibc

[gentoo-dev] time64 ABI fix coming to upstream glibc

[Florian Weimer]

The <utmp.h> and <utmp.h> headers had a bug that the on-disk structures
defined there could change size on some targets when _TIME_BITS was set
to 64.  This is obviously wrong because the files are not going to
magically change their layout because the application accessing them was
built in a specific way.  We're going to fix this in glibc upstream on
the stable release branches, going all the way back to glibc 3.34 (the
first release with this kind of time64 support).  After the fix, the
_TIME_BITS definition will no longer impact struct layout.  Usually,
that means epoch fields are 32-bits wide, to match co-installable
architectures.

To extend the usable life-time of these interfaces somewhat, glibc 2.40
changes epoch fields to unsigned types in these structures.  This change
is specific to the upcoming glibc 2.40 release, I do not plan to
backport it.

Thanks,
Florian

Re: [gentoo-dev] time64 ABI fix coming to upstream glibc

[Sam James]

Florian Weimer <fweimer@redhat.com> writes:

> The <utmp.h> and <utmp.h> headers had a bug that the on-disk structures
> defined there could change size on some targets when _TIME_BITS was set
> to 64.  This is obviously wrong because the files are not going to
> magically change their layout because the application accessing them was
> built in a specific way.  We're going to fix this in glibc upstream on
> the stable release branches, going all the way back to glibc 3.34 (the
> first release with this kind of time64 support).  After the fix, the
> _TIME_BITS definition will no longer impact struct layout.  Usually,
> that means epoch fields are 32-bits wide, to match co-installable
> architectures.
>
> To extend the usable life-time of these interfaces somewhat, glibc 2.40
> changes epoch fields to unsigned types in these structures.  This change
> is specific to the upcoming glibc 2.40 release, I do not plan to
> backport it.

Thank you for the heads-up Florian. We haven't yet started our time64
migration - the plan is to start playing with it over the next few
months, so the timing has worked out well for us. We'll make sure the
fixes are pulled in before we solidify anything beyond experiments.

I'm trying not to wait *too* late to start, just in case we do end up
finding any other problems like this, rather than finding them years
down the line when it's too late to fix anything.

>
> Thanks,
> Florian

thanks,
sam