[Bug time/31510] New: Wrong type for timeval.tv_usec on 32-bit archs with _TIME_BITS=64

[Bug time/31510] New: Wrong type for timeval.tv_usec on 32-bit archs with _TIME_BITS=64

[simon.chopin at canonical dot com]

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

            Bug ID: 31510
           Summary: Wrong type for timeval.tv_usec on 32-bit archs with
                    _TIME_BITS=64
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: simon.chopin at canonical dot com
  Target Milestone: ---

POSIX documents struct timeval as follows:

struct timeval {
    time_t      tv_sec;         /* seconds */
    suseconds_t tv_usec;        /* microseconds */
};
Since bdc4782744df73a8c0559985c54b5b6b9c7a4a74 ("y2038: Add __USE_TIME_BITS64
support for struct timeval") tv_usec can have __suseconds64_t when using 64-bit
time, however suseconds_t is unconditionally typedefed to __suseconds_t.

That leads to the following:

ubuntu@mantic-armhf:~$ cat test.c
#include <sys/time.h>
#include <stdio.h>
#include <assert.h>

int main(void)
{
        struct timeval tv;
        printf("tv_usec: %d, suseconds_t: %d\n", sizeof(tv.tv_usec),
sizeof(suseconds_t));
        assert(sizeof(tv.tv_usec) == sizeof(suseconds_t));
        return 0;
}
ubuntu@mantic-armhf:~$ gcc test.c && ./a.out
tv_usec: 4, suseconds_t: 4
ubuntu@mantic-armhf:~$ gcc -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 test.c &&
./a.out
tv_usec: 8, suseconds_t: 4
a.out: test.c:9: main: Assertion `sizeof(tv.tv_usec) == sizeof(suseconds_t)'
failed.
Aborted (core dumped)

We noticed this when running the conformance tests on Ubuntu Noble, where we've
set _TIME_BITS=64 in the default GCC flags as part of the ongoing t64
transition.

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

[Bug time/31510] Wrong type for timeval.tv_usec on 32-bit archs with _TIME_BITS=64

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

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

[Bug time/31510] Wrong type for timeval.tv_usec on 32-bit archs with _TIME_BITS=64

[adhemerval.zanella at linaro dot org]

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

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Yes, this was an overlook which I am not fully sure how to handle without
breaking 'current' 64 time ABI. Maybe we can follow the timespec one,
time/bits/types/struct_timespec.h, used 32 bit suseconds_t and add proper
paddings depending of the endianess.

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

[Bug time/31510] Wrong type for timeval.tv_usec on 32-bit archs with _TIME_BITS=64

[jsm28 at gcc dot gnu.org]

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

--- Comment #2 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Shouldn't we fix how suseconds_t is defined in glibc in the 64-bit time case?
It's not as if any interfaces in glibc use suseconds_t other than as part of
struct timeval (though we should still warn in NEWS about potential
compatibility issues for any interfaces using suseconds_t in third-party
libraries).

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

[Bug time/31510] Wrong type for timeval.tv_usec on 32-bit archs with _TIME_BITS=64

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
(Not that suseconds_t *needs* to be 64-bit to store values from 0 to 999999,
but there's nothing wrong with it being 64-bit either, it just needs to agree
with the type of tv_usec.)

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

[Bug time/31510] Wrong type for timeval.tv_usec on 32-bit archs with _TIME_BITS=64

[adhemerval.zanella at linaro dot org]

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

--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Joseph Myers from comment #2)
> Shouldn't we fix how suseconds_t is defined in glibc in the 64-bit time
> case? It's not as if any interfaces in glibc use suseconds_t other than as
> part of struct timeval (though we should still warn in NEWS about potential
> compatibility issues for any interfaces using suseconds_t in third-party
> libraries).

That's why I am not fully sure which would be the best way, since this strictly
is an ABI break.  

At least using the timespec trick to keep the type as currently defined should
not cause any issue (since the type holds all potential values), and it should
be back-portable.

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

[Bug time/31510] Wrong type for timeval.tv_usec on 32-bit archs with _TIME_BITS=64

[simon.chopin at canonical dot com]

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

--- Comment #5 from Simon Chopin <simon.chopin at canonical dot com> ---
FWIW, we've actually seen at least one package seemingly failing to build
because of this issue: 
https://launchpadlibrarian.net/720254657/buildlog_ubuntu-noble-armhf.libflorist_2022.0.1~20220616-5_BUILDING.txt.gz

> posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed is 64

I didn't dig into what exactly they're doing there.

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