Re: 64 bit time_t on riscv32

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 15/01/24 19:26, Rich Felker wrote:
> On Mon, Jan 15, 2024 at 04:55:30PM -0300, Adhemerval Zanella Netto wrote:
>>
>>
>> On 15/01/24 10:40, Florian Weimer via Libc-help wrote:
>>> * Antonios Salios via Libc-help:
>>>
>>>> According to a kernel maintainer, the __USE_TIME_BITS64 macro should be
>>>> set on architectures that use 64-bit time [2], otherwise the kernel
>>>> headers will not be able to pick the correct definition.
>>>
>>> __USE_TIME_BITS64 is an internal glibc macro.  It is not used on
>>> architectures which have a 64-bit time_t by default.
>>>
>>> Surely the UAPI headers know which time size the architecture uses in
>>> the kernel interface, and can be written arcordingly?
>>
>> The use of a glibc internal definition on a kABI header is not really
>> a good design.  This seems to be only user so far, so I suggest to fix
>> on the kernel to not tie to a glibc internal definition. 
>>
>> CCing Rich from musl that most likely would want to see this fixed. The
>> Android developers might be interested.
> 
> At the time this was done, I understood __USE_TIME_BITS64 as the
> contract between the userspace implementation and the kernel uapi
> headers to say "we use 64-bit time_t and want the 64-bit version of
> the types/ioctls/etc." That's what musl does -- we always define
> __USE_TIME_BITS64, unconditionally. I haven't read this whole thread,
> but it sounds like glibc's rv32 port is breaking their own contract
> and not defining __USE_TIME_BITS64...

My understanding was __USE_TIME_BITS64 would be required only for ABIs
that actually would multiple time_t sizes and the glibc 64 bit time_t 
supported was added on this assumption.  However, the design document 
does state __USE_TIME_BITS64 would be defined even for architectures 
where is does not require it.  I it was not really caught in development
because the design creator was not really much involved at the time.

I think it should be feasible to fix it, although backporting it would
generate a quite large patch.