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

[Lukasz Majewski]

Hi Adhemerval,

> On 13/11/2020 11:42, Lukasz Majewski wrote:
> > Hi Adhemerval,
> >   
> >> On 12/11/2020 19:02, Lukasz Majewski wrote:  
> >>> Those issues are not resolved since 2012, so I do guess that those
> >>> are not very urgent or easily solvable.
> >>>
> >>> The Y2038 support will have consistent name scheme for functions
> >>> aliased (e.g. foo) to 64 bit versions (__foo64 or __foo_time64).
> >>> If we can get away with having the latter exported, so they will
> >>> not clash, it shall be Ok.     
> >>
> >> I would guess there are not easily solvable, so I would expect that
> >> the default _TIME_BITS for 32-bit architecture with legacy 32-bit
> >> time_t support would still be '32'.   
> > 
> > No,  in this case we would use the names without any suffix - e.g.
> > clock_gettime instead of __clock_gettime64.  
> 
> The linkage name is already handle by the __REDIRECT (if compiler
> supports is) macro, which creates a linkage alias.  The code will
> call clock_gettime, but static linking will bind to __clock_gettime64.

I'm a bit confused now.

Please correct me if I'm wrong, but on 32 bit system (ARM) with
__TIMESIZE != 64 and _TIME_BITS==32 (or not defined) we will be linked
into clock_gettime (not __clock_gettime64).

> 
> >   
> >> This unfortunately would require
> >> to be explicit enable on the projects build system and it might not
> >> straightforwards to enable worldwide since we got reports that
> >> recent debian builds still do not enable LFS support on all
> >> packages.  
> > 
> > I think that it will not be so problematic in the end of the day.
> > When we set default minimal supported kernel version to 5.1+, the
> > _TIME_BITS = 64 can be enabled by default (on ports with
> > __WORDSIZE=32 && __TIMESIZE != 64). Until then users would be
> > allowed to pass it with -D/Makefile.  
> 
> I don't think this is that simple for 32-bit ports with 32-bit time_t,
> no without fixing or discussing the LFS bug reports.  For
> _FILE_OFFSET_BITS=64 I think the solution outline by Rich on comment#2
> from BZ#14106 should be suffice (rename all the *64 functions to __*64
> and update the headers accordingly), we will still need to keep
> exporting the symbols for both compatibility and _LARGEFILE64_SOURCE.
> 

Ok, I see.

However, this is just a side problem to Y2038, so it shouldn't be a
showstopper.

> >   
> >>
> >> I do think we should eventually enable both LFS and 64-bit time as
> >> default for *all* architectures; this solves a lot of possible
> >> issues.  
> > 
> > Yes. I do agree.
> >   
> >>  
> >>>>
> >>>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=14106
> >>>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=15766 
> >>>> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=13047    
> >>  
> > 
> > 
> > 
> > 
> > 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 
> 




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/20201113/3f4fcdcc/attachment.sig>