This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:
> <*+%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:

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

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

Attachment: pgp3Y5JVdX_c4.pgp
Description: OpenPGP digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]