Re: [PATCH] sys/types.h: Define new types: [s]nseconds_t

["Zack Weinberg" <zack@owlfolio.org>]

On Tue, Dec 7, 2021, at 6:19 AM, Alejandro Colomar wrote:
> For symmetry with the existing [s]useconds_t types.
>
> The timespec(3) structure uses long for tv_nsec,
> except if __x86_64__ && __ILP32__,
> in which case it uses long long.
> Let's define a stable type that can be relied upon by users,
> for example for creating pointers.

I endorse the _concept_ of this change, regardless of whether the POSIX and C committees like it.  That said, there are some technical issues with the patch as is:

> +#if defined __x86_64__ && defined __ILP32__
> +typedef unsigned long long nseconds_t;
> +typedef long long snseconds_t;
> +#else
> +typedef unsigned long nseconds_t;
> +typedef long snseconds_t;
> +#endif

As Andreas pointed out, this belongs in bits/types.h, defining __nseconds_t and __snseconds_t.  Also, the choice of underlying type should be controlled by a new macro defined by bits/wordsize.h, so that we don't have x86-specific ifdeffage in bits/types.h.

There should then be headers <bits/types/nseconds_t.h> and <bits/types/snseconds_t.h> that define the user-namespace typedefs in terms of the __-prefixed types.  <bits/types/struct_timespec.h> should include <bits/types/snseconds_t.h> and use __snseconds_t (*not* snseconds_t) in the definition of struct timespec; <sys/types.h> should include both headers.

See if you can clean up the ifdef mess in the definition of struct timespec at the same time.  It appears to me, just looking at that, that this is *not* just an issue for x86-64 with the x32 ABI.

Tangentially, should we actually have nseconds_t if nothing's going to use it?

zw