[RFC v2 1/2] sys/types.h: Define new type: snseconds_t

[Zack Weinberg]

On Tue, Dec 7, 2021, at 10:05 PM, Rich Felker wrote:
> On Tue, Dec 07, 2021 at 09:26:59PM -0500, Zack Weinberg wrote:
>> On Tue, Dec 7, 2021, at 7:29 PM, Rich Felker wrote:
>> >
>> > This is a non-starter because the relevant standards already require
>> > the tv_nsec member to have type long.
>> 
>> That requirement is a defect in the standards, and I see no reason
>> why this particular defect should be granted 'we're stuck with this'
>> status.
>
> When the standard codifies existing *universal* practice without
> introducing a gratuitous typedef

Universal practice is not necessarily correct.  It was an error to define a structure type that's passed across the user/kernel boundary, with a field whose type isn't a typedef name.  It has *always* been an error.  And I have yet to see a compelling reason why the error should not be corrected.

>> > x32 just needs to be fixed to match the requirement.
>> 
>> This doesn't just affect x32, it affects every ABI with 32-bit long
>> and 64-bit time_t. Look at the ifdef mess in glibc
>> bits/types/struct_timespec.h if you don't believe me.
>
> They all got it right -- tv_nsec has type long (32-bit). There is
> nothing affected by the issue described here except x32, and it's
> easily fixed. We've always had it right on musl x32 too.

I looked through the source code to musl and I could not find the definition of struct timespec.  It appears that it's supposed to be defined by <bits/alltypes.h> but that's a generated file and the only piece of the generator I could find (tools/mkalltypes.sed) doesn't seem to have code to emit a definition of struct timespec, but it's not in arch/*/bits/alltypes.h.in either.  Where should I be looking?

Having said that, I don't actually _care_ whether the spec bug can be papered over with sufficient cleverness in the user-side definition of struct timespec.  It is still a bug in the spec.

zw