[Bug time/30701] New: getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

["eggert at cs dot ucla.edu" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

            Bug ID: 30701
           Summary: getutxent misbehaves on 32-bit x86 when _TIME_BITS=64
           Product: glibc
           Version: 2.37
            Status: NEW
          Severity: normal
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 15024
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15024&action=edit
Source code illustrating the bug, when compiled with -m32

A user ran into this problem with Coreutils 'who'.[1] Although we have a
workaround in Gnulib[2] it's hacky as it delves into glibc internals.

This bug is distinct from glibc bug 28146 because it occurs now, not in the
year 2038.

Compile and run the attached program on Fedora 38 with 'gcc -m32 badutmpx.c;
./a.out'. I see output lines like this:

user=reboot id=~~ line=~ pid=0 type=2 tv=2385233251778666.000000

The timestamp is wrong, and the line should look like this:

user=reboot id=~~ line=~ pid=0 type=2 tv=1689108586.555355

The problem is that getutmpx is not converting the external format in
/var/run/utmp with 32-bit timestamps to in-memory format, where time_t is 64
bits not 32.

[1]: https://bugs.gnu.org/64937
[2]: https://lists.gnu.org/r/bug-gnulib/2023-07/msg00159.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.