Re: 64 bit time_t on riscv32

[Rich Felker <dalias@libc.org>]

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...

Rich