login: Use unsigned 32-bit types for seconds-since-epoch

These fields store timestamps when the system was running.  No Linux
systems existed before 1970, so these values are unused.  Switching
to unsigned types allows continued use of the existing struct layouts
beyond the year 2038.

This change is relevant to some 64-bit architectures which opted
to use 32-bit timestamps, for compatibility with co-installed
32-bit binaries (__WORDSIZE_TIME64_COMPAT32).  For consistency,
if there is a 64-bit architecture that is coinstallable, define
__WORDSIZE_TIME64_COMPAT32 to 1 on the 32-bit architectyre as well.

The intent is to give distributions more time to switch to improved
interfaces that also avoid locking/data corruption issues.

Tested on aarch64-linux-gnu, i686-linux-gnu, powerpc-linux-gnu,
powerpc64-linux-gnu, powerpc64le-linux-gnu, s390-linux-gnu,
s390x-linux-gnu, x86_64-linux-gnu.

---
 NEWS                                          | 6 +++++-
 bits/utmp.h                                   | 4 ++--
 sysdeps/gnu/bits/utmpx.h                      | 2 +-
 sysdeps/mips/bits/wordsize.h                  | 6 +-----
 sysdeps/powerpc/powerpc32/bits/wordsize.h     | 3 +--
 sysdeps/sparc/sparc32/bits/wordsize.h         | 2 +-
 sysdeps/sparc/sparc64/bits/wordsize.h         | 3 +--
 sysdeps/unix/sysv/linux/sparc/bits/wordsize.h | 3 +--
 sysdeps/x86/bits/wordsize.h                   | 5 ++---
 9 files changed, 15 insertions(+), 19 deletions(-)


base-commit: a4ed0471d71739928a0d0fa3258b3ff3b158e9b9

On 4/3/24 11:39, Florian Weimer wrote:
> For consistency,
> if there is a 64-bit architecture that is coinstallable, define
> __WORDSIZE_TIME64_COMPAT32 to 1 on the 32-bit architectyre as well.

Could you explain the advantage of consistency here? User code almost 
invariably assignes ut_tv.tv_sec to time_t (this is true of every 
instance I found of ut_tv in Gnulib source code, for example). So 
changing this field's type on platforms where time_t is 32 bits will 
likely be ineffective in practice, and might cause more problems than it 
cures.

Since the _TIME_BITS==32 world is going away anyway by 2038, it might be 
better to leave the field types unchanged in that world, to lessen 
compatibility glitches before that world gives up its ghost.

* Paul Eggert:

> On 4/3/24 11:39, Florian Weimer wrote:
>> For consistency,
>> if there is a 64-bit architecture that is coinstallable, define
>> __WORDSIZE_TIME64_COMPAT32 to 1 on the 32-bit architectyre as well.
>
> Could you explain the advantage of consistency here? User code almost
> invariably assignes ut_tv.tv_sec to time_t (this is true of every
> instance I found of ut_tv in Gnulib source code, for example). So
> changing this field's type on platforms where time_t is 32 bits will
> likely be ineffective in practice, and might cause more problems than
> it cures.

Few applications with a 32-bit time_t will work once there is a value in
this field with the MSB set.  So the relevant case is applications that
were built with -D_TIME_BITS=64, and there the consistent behavior with
the 64-bit architecture helps.

> Since the _TIME_BITS==32 world is going away anyway by 2038, it might
> be better to leave the field types unchanged in that world, to lessen
> compatibility glitches before that world gives up its ghost.

This is an on-disk format that doesn't change with -D_TIME_BITS=64.

Thanks,
Florian

On 04/04/24 02:09, Florian Weimer wrote:
> * Paul Eggert:
> 
>> On 4/3/24 11:39, Florian Weimer wrote:
>>> For consistency,
>>> if there is a 64-bit architecture that is coinstallable, define
>>> __WORDSIZE_TIME64_COMPAT32 to 1 on the 32-bit architectyre as well.
>>
>> Could you explain the advantage of consistency here? User code almost
>> invariably assignes ut_tv.tv_sec to time_t (this is true of every
>> instance I found of ut_tv in Gnulib source code, for example). So
>> changing this field's type on platforms where time_t is 32 bits will
>> likely be ineffective in practice, and might cause more problems than
>> it cures.
> 
> Few applications with a 32-bit time_t will work once there is a value in
> this field with the MSB set.  So the relevant case is applications that
> were built with -D_TIME_BITS=64, and there the consistent behavior with
> the 64-bit architecture helps.

This helps only architectures with __WORDSIZE_TIME64_COMPAT32, so it does
not really solve the issue for all legacy platforms.  I still prefer if
we just deprecate this whole interface, since from other legacy ABI history
(non-LFS interface) programs will keep using it until something breaks.

> 
>> Since the _TIME_BITS==32 world is going away anyway by 2038, it might
>> be better to leave the field types unchanged in that world, to lessen
>> compatibility glitches before that world gives up its ghost.
> 
> This is an on-disk format that doesn't change with -D_TIME_BITS=64.
> 
> Thanks,
> Florian
>

* Adhemerval Zanella Netto:

> On 04/04/24 02:09, Florian Weimer wrote:
>> * Paul Eggert:
>> 
>>> On 4/3/24 11:39, Florian Weimer wrote:
>>>> For consistency,
>>>> if there is a 64-bit architecture that is coinstallable, define
>>>> __WORDSIZE_TIME64_COMPAT32 to 1 on the 32-bit architectyre as well.
>>>
>>> Could you explain the advantage of consistency here? User code almost
>>> invariably assignes ut_tv.tv_sec to time_t (this is true of every
>>> instance I found of ut_tv in Gnulib source code, for example). So
>>> changing this field's type on platforms where time_t is 32 bits will
>>> likely be ineffective in practice, and might cause more problems than
>>> it cures.
>> 
>> Few applications with a 32-bit time_t will work once there is a value in
>> this field with the MSB set.  So the relevant case is applications that
>> were built with -D_TIME_BITS=64, and there the consistent behavior with
>> the 64-bit architecture helps.
>
> This helps only architectures with __WORDSIZE_TIME64_COMPAT32, so it does
> not really solve the issue for all legacy platforms.

We can add more __WORDSIZE_TIME64_COMPAT32=1 definitions.

> I still prefer if we just deprecate this whole interface, since from
> other legacy ABI history (non-LFS interface) programs will keep using
> it until something breaks.

I don't disagree, I just want to give distributions the option to
backport a reviewed patch with a workaround that appears not to require
much application porting.  I believe many of us are preparing toolchains
for distributions that are running close to the 2038 cliff.

Thanks,
Florian

On 05/04/24 09:52, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 04/04/24 02:09, Florian Weimer wrote:
>>> * Paul Eggert:
>>>
>>>> On 4/3/24 11:39, Florian Weimer wrote:
>>>>> For consistency,
>>>>> if there is a 64-bit architecture that is coinstallable, define
>>>>> __WORDSIZE_TIME64_COMPAT32 to 1 on the 32-bit architectyre as well.
>>>>
>>>> Could you explain the advantage of consistency here? User code almost
>>>> invariably assignes ut_tv.tv_sec to time_t (this is true of every
>>>> instance I found of ut_tv in Gnulib source code, for example). So
>>>> changing this field's type on platforms where time_t is 32 bits will
>>>> likely be ineffective in practice, and might cause more problems than
>>>> it cures.
>>>
>>> Few applications with a 32-bit time_t will work once there is a value in
>>> this field with the MSB set.  So the relevant case is applications that
>>> were built with -D_TIME_BITS=64, and there the consistent behavior with
>>> the 64-bit architecture helps.
>>
>> This helps only architectures with __WORDSIZE_TIME64_COMPAT32, so it does
>> not really solve the issue for all legacy platforms.
> 
> We can add more __WORDSIZE_TIME64_COMPAT32=1 definitions.
> 
>> I still prefer if we just deprecate this whole interface, since from
>> other legacy ABI history (non-LFS interface) programs will keep using
>> it until something breaks.
> 
> I don't disagree, I just want to give distributions the option to
> backport a reviewed patch with a workaround that appears not to require
> much application porting.  I believe many of us are preparing toolchains
> for distributions that are running close to the 2038 cliff.

So maybe add deprecated on utmp/utmpx functions, along with a NEWS entry
stating these function will make noop in future glibc release?

* Adhemerval Zanella Netto:

>>> I still prefer if we just deprecate this whole interface, since from
>>> other legacy ABI history (non-LFS interface) programs will keep using
>>> it until something breaks.
>> 
>> I don't disagree, I just want to give distributions the option to
>> backport a reviewed patch with a workaround that appears not to require
>> much application porting.  I believe many of us are preparing toolchains
>> for distributions that are running close to the 2038 cliff.
>
> So maybe add deprecated on utmp/utmpx functions, along with a NEWS entry
> stating these function will make noop in future glibc release?

I added a second NEWS entry in v2.

Thanks,
Florian