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

[Lukasz Majewski]

Hi Joseph, Adhemerval,

> On Mon, 9 Nov 2020, Lukasz Majewski wrote:
> 
> > > 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)?  
> 
> I think "#define stat __stat64_time64" is unsafe, since people may do 
> "#undef stat" to get a function rather than a macro (and thereby
> suppress the macro expansion for the struct tag as well).
> 
> I'm less sure there would be any problems with "#define timespec 
> __timespec64".  The POSIX namespace rules are clearer on e.g. what's 
> reserved with file scope, than on what's reserved as a macro name
> that the user mustn't undefine.
> 

Please correct me if I'm wrong, but the scheme shall be consistent.
Which approach shall be taken then?


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/20201110/979d39e8/attachment.sig>