This is the mail archive of the libc-alpha@sourceware.org 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 v3 2/5] y2038: Introduce internal for glibc struct __timespec64


Hi Andreas,

> On Mai 07 2019, Lukasz Majewski <lukma@denx.de> wrote:
> 
> > Hi Andreas,
> >  
> >> On Mai 07 2019, Lukasz Majewski <lukma@denx.de> wrote:
> >>   
> >> > +struct __timespec64
> >> > +{
> >> > +  __time64_t tv_sec;         /* Seconds */
> >> > +# if BYTE_ORDER == BIG_ENDIAN
> >> > +  int tv_pad: 32;            /* Padding named for
> >> > checking/setting */
> >> > +  __int32_t tv_nsec;         /* Nanoseconds */
> >> > +# else
> >> > +  __int32_t tv_nsec;         /* Nanoseconds */
> >> > +  int tv_pad: 32;            /* Padding named for
> >> > checking/setting */ +# endif    
> >> 
> >> No need to use a bitfield, since the padding is not fractional.  
> >
> > That bitfield is for following reasons:
> >
> > 1. Have a backup plan in the case if we need to copy and clear the
> > padding anyway before passing this structure to the kernel in the
> > future (as recently we discovered that for example x32 has a kernel
> > bug with clearing it).
> >
> > 2. Kernel syscalls (e.g. clock_settime64) expects on those systems
> > two values - each 8 bytes. To avoid any nasty surprises the explicit
> > padding was added.  
> 
> None of that requires a bitfield.

For 32 bit systems with 64 bit time_t we would have following
situation:

struct timespec:
	-> tv_sec (8 B)
	-> tv_nsec (4 B -> must be long as of POSIX) [*]

This would have 16B size (sizeof() would return 16B [1])


My point is if we do need at any point in time to clear this padding
(due to e.g. kernel bug when passing data to syscalls [2] or solve issue
as presented in [*]).


Note:

[*] - the x32 ABI of x86_64 has long 8B and there are some issues with
POSIX compliance
https://sourceware.org/bugzilla/show_bug.cgi?id=16437

[1] - as discussed:
http://www.catb.org/esr/structure-packing/#_structure_alignment_and_padding

[2] -
https://lore.kernel.org/lkml/20190429131951.471701-1-arnd@arndb.de/

> 
> Andreas.
> 




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: pgpKN9oPR7AEB.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]