[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