[PATCH 3/3] login: Make user accounting database no-op

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Wed Aug 7 19:53:54 GMT 2024



On 07/08/24 16:27, Paul Eggert wrote:
> On 2024-08-07 12:06, Thorsten Kukuk wrote:
>> How should that solve the Y2038 issue?
>> I'm not aware of any application which interprets the int32 time value
>> as unsigned value.
> 
> Coreutils and other Gnulib-based programs do, as of this Gnulib patch about based on a suggestion by Andreas about a year ago:
> 
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=0a7a71a4f24b4608662b4532bd17aef758f049fd
> 
> 
>> And how do applications find out, if the value was written as int or as uint?
> 
> They assume the latter. Quoting from the patch:
> 
>> -      int tv_sec;            /* Seconds.  */
>> +      /* Seconds.  Unsigned not signed, as glibc did not exist before 1970,
>> +         and if the format is still in use after 2038 its timestamps
>> +         will surely have the sign bit on.  This hack stops working
>> +         at 2106-02-07 06:28:16 UTC.  */
>> +      unsigned int tv_sec;
> 
> 
>> For me this is not a solution for the Y2038, that issue still exists.
> 
> It does move the goalposts from 2038 to 2106.
> 
> I agree that it's not ideal, and that we should instead fix the API.

I think to really fixing the API would require to move the utmp/utmpx handling
out of the process, otherwise we will need quite complex solution to proper
BZ#24492.

And these issues exist for a long time, without much traction to fix on glibc.
The unsigned trick is a rubber band, but the implementation is still clunky in
some parts.

That's why I still think best course of action is just to deprecate this API
on glibc side and move to what Thorsten has suggested some years ago.


More information about the Libc-alpha mailing list