[PATCH 2/3] msqid: Provide internal copy of struct __msqid64_ds

[Lukasz Majewski]

Hi Joseph, Adhemerval,

> On Mon, 9 Nov 2020, Adhemerval Zanella via Libc-alpha wrote:
> 
> > On 06/11/2020 14:37, Joseph Myers wrote:  
> > > On Fri, 6 Nov 2020, Lukasz Majewski wrote:
> > >   
> > >> 3. The exported header (from point 1) shall have:
> > >>
> > >> #if __TIMESIZE == 32 && defined __USE_TIME_BITS64
> > >> # define timespec __timespec64
> > >> #endif  
> > > 
> > > You'll need to make sure that's permitted under the namespace
> > > reservations in POSIX.
> > > 
> > > For the cases where a struct tag has the same name as a function
> > > (e.g. stat), #undef of the function name is definitely allowed
> > > for user programs, so relying on defining the struct tag as a
> > > macro is probably unsafe in that case.  
> > 
> > In these which alternative would be better?  Export __timespec64 as 
> > different name or use the strategy to redefine timespec to different
> > member sizes and layout depending of time ABI?  
> 
> If in a particular case defining the struct tag as a macro is unsafe,

Could you explain why having construct as:

#define timespec __timespec64 in ./time/bits/types/struct_timespec.c is
unsafe (after having the file ./time/bits/types/struct___timespec64.c
exported)?

What are the problems with such approach? Would it not make the "posix"
exported headers content polluted and make this test fail?

(I had such case when by mistake I've added some extra defines to some
exported headers).

> we can't avoid having different definitions of the contents of the
> same struct tag depending on how _TIME_BITS is defined.

Have I understood correctly that we shall then stick to the approach
to have exported only e.g. struct timespec and have corresponding
internal for glibc structure - __timespec64, which matches the former's
ABI? Such approach is now used in my WIP patch [1].

The chosen approach is quite important in terms of the work necessary
for Y2038 support. I would opt for having the consensus reached sooner
than latter?

> 

Links:

[1] -
https://github.com/lmajewski/y2038_glibc/commit/cc68c0498f82697e6f87418e148a19ded2d5aec7#diff-8297a1191cc06a8a7af6fc6ac33af4bef2d7d72efd901d1634d910b56631e0c7R11


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20201109/3ad6a23e/attachment.sig>