Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define

[Lukasz Majewski <lukma at denx dot de>]

Hi Florian, Rich,

> * Rich Felker:
> 
> >> If we give the padding a name, this will not work on big-endian
> >> targets
> >> 
> >>   ts?(struct timespec[]){ts->tv_sec, ts->tv_nsec}:0
> >> 
> >> because the padding is in the middle, and ts->tv_nsec is copied
> >> into the padding.  
> >
> > While it may be desirable for compatibility with wrong code for this
> > sort of initializer to work, there is no specification on the order
> > or lack of other named members in timespec. Correct initialization
> > has to use designated initializers. I tried to sidestep the problem
> > by using *ts, but indeed I botched that; it would not zero the
> > padding.  
> 
> Wrong initializers are fairly common, unfortunately:
> 
> <https://codesearch.debian.net/search?q=struct+timespec.*+%3D+%5C%7B%5Cs*%5B%5E+.0%5D&literal=0&perpkg=1>

As fair as I remember I had a discussion about the padding and explicit
initialization with Joseph:
https://patchwork.ozlabs.org/patch/1066737/#2155140


There was also a conclusion regarding explicit clearing of the padding
if necessary - kernel shall do it (or to be more precise - kernel will
perform modulo operation of the number passed to it from glibc if
needed).

> 
> >> If we do not give the padding a name, the expression leaves the
> >> padding uninitialized (C11: “Unnamed members of structure objects
> >> have indeterminate value even after initialization.”).
> >> 
> >> And who should do this?  I think for pselect, glibc has to do it,
> >> but what about ioctls and socket options?  
> >
> > These need translation logic anyway or post-time64 software won't
> > run on pre-time64 kernels. See
> >
> > https://git.musl-libc.org/cgit/musl/commit/?id=51fd67fcbfa598e2fe1885b517451b84c0bfe3b7
> >
> > So it's not a big deal to also zero the padding if needed.  
> 
> That's not in the patch, right?
> 
> Is the set of emulations required fixed?  In the sense that there will
> be no new kernel features which are 32-bit only?
> 
> Only in that case, I think userspace emulation is feasible.  Getting
> full coverage for ioctls will still be difficult, I think.
> 
> I wonder if we should define a proper type (with long long int
> members) for applications to use with ioctls.  That would enable
> concise syntax and documenting intent.
> 
> Or we could work with WG14 and POSIX and introduce a snseconds_t type,
> formally blessing what x32 and the kernel already do.  If we can get
> this changed, I'm not sure if supporting older C and POSIX standards
> (which mandate long) is worth the cost.
> 
> > Ideally though the kernel should handle this right, especially for
> > new ioctls/sockopts added post-time64 where there's no need for
> > fallback translation.  
> 
> Let's hope so.
> 
> Thanks,
> Florian



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Attachment: pgp3Y5JVdX_c4.pgp
Description: OpenPGP digital signature