Re: POSIX.1-2024 requires 64-bit time_t

[Collin Funk <collin.funk1@gmail.com>]

Hi Alejandro,

Alejandro Colomar <alx@kernel.org> writes:

> POSIX.1-2024 seems to require a 64-bit (or wider) time_t.  I don't know
> how's the state of things as of now in glibc, so would you mind checking
> the time_t(3type) manual page and letting me know if anything needs to
> be updated or moved to history?
>
> At first glancce, I see
>
> DESCRIPTION
>        time_t Used for time in seconds.  According to POSIX,
>               it is an integer type.
>
> where I'll have to append "of at least 64 bits".  Then, there's
>
> NOTES
>        On some architectures, the width  of  time_t  can  be
>        controlled  with  the  feature test macro _TIME_BITS.
>        See feature_test_macros(7).
>
> Which sounds redundant with the new requirements.  That sounds like it's
> for architectures that are non-conforming only, right?  In the
> conforming ones, it wouldn't make sense.  So, we'll need to clarify
> which architectures are conforming and which are not.  Please let me
> know.

I documented this in glibc in commit
363bbdbd2aeaae1e00f3872f2ba19a4a3c17bdf1:

    manual: Mention POSIX-1.2024 requires time_t to be 64 bit or wider.
    
    * manual/time.texi (Time Types): Mention POSIX-1.2024 requires 64 bit
    time_t.
    
    Signed-off-by: Collin Funk <collin.funk1@gmail.com>
    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

But as you mention and as documented in the manual, some older platforms
default to 32-bits unless _TIME_BITS is set to 64:

    Currently the @code{time_t} type is 64 bits wide on all platforms
    supported by @theglibc{}, except that it is 32 bits wide on a few
    older platforms unless you define @code{_TIME_BITS} to 64.

I'll have to investigate the full list of architectures which that is
the case.

Collin