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

[Rich Felker <dalias@libc.org>]

On Wed, Dec 08, 2021 at 09:34:39AM -0500, Zack Weinberg wrote:
> 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.

This is your ideology. I don't agree with it, and I hope others won't
too. Stop treating it as Truth folks are supposed to automatically
agree with you on.

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

include/alltypes.h.in is also used, and contains:

STRUCT timespec { time_t tv_sec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER==4321); long tv_nsec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER!=4321); };

which is just time_t tv_sec and long tv_nsec surrounded by the
appropriate anonymous padding for endianness and sizeof(long).

The same could be achieved writing it out explicitly for the different
options but we wanted it to be automatically consistent using a single
definition.

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

No "cleverness" is needed here. Nothing at all would be needed if the
kernel weren't trying to be "clever" and match the layout between
32-bit and 64-bit archs; since it is, you just need padding in the
right place to match that. You're making a huge meal over something
that is incredibly simple.

Rich