Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

Joseph S. Myers
2014-05-16T23:47:51Z

On Sat, 17 May 2014, H. Peter Anvin wrote:

> On 05/15/2014 01:38 PM, Arnd Bergmann wrote:
> >
> > For practical purposes in the kernel, we may still want to use 64-bit
> > nanoseconds: if we use a 96 bit struct timespec, that would be incompatible
> > with the native type on 64-bit kernels, thus complicating the syscall
> > emulation layer.
> >
> > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > problematic.
>
> struct timespec is specified in POSIX as having type "long" for tv_nsec.
> This, as Linus pointed out, is totally braindamaged.

long is a perfectly reasonable type for this purpose - it's guaranteed to
have enough precision. ISO C11 follows POSIX in the definition of struct
timespec.

> x32 does not follow POSIX (Linus pretty much dictated that), and instead
> does the __kernel_suseconds_t to match the native kernel type. The
> proposal at some point was to try to push a snseconds_t into POSIX.

If the x32 kernel won't be fixed to treat the high part as padding then
glibc will need fixing to copy all struct timespec values passed to the
kernel and clear the padding when copying (really, fixing that bug would
need such copying anyway unless --enable-kernel is used to allow a fixed
kernel to be assumed). In any case, we should not put any more ports into
glibc with that x32 bug; "long" and an explicit padding field is the way
to go (and copying / zeroing if the kernel doesn't treat that padding
field as padding).

Adding snseconds_t to POSIX seems pointless when there is no need for this
field to store values that can't fit in "long". Even if it were added,
good practice would say that implementations should keep using "long"
whenever possible for compatibility with existing applications (just like
the ISO C recommendation "The types used for size_t and ptrdiff_t should
not have an integer conversion rank greater than that of signed long int
unless the implementation supports objects large enough to make this
necessary.").

If you were designing from scratch, no doubt a typedef such as snseconds_t
would be there, but with real-world APIs that have accumulated over time,
deviating from "long" now is a bad idea.

--
Joseph S. Myers
joseph@codesourcery.com