Re: namespace pollution? clone()

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Mon, Aug 01, 2022 at 16:50:14 +0200, Thomas Klausner wrote:

> On Mon, Aug 01, 2022 at 05:45:23PM +0300, Valeriy E. Ushakov wrote:
> > Shouldn't we expose __clone(2) (the real symbol in the reserved
> > namespace) under _NETBSD_SOURCE and only hide clone(2) weak alias
> > under _GNU_SOURCE?  You kinda sidestep some potential issues here in
> > this case b/c __clone is an assembler syscall stub, so there's no C
> > source that implements __close() that has to see the declaration.
> 
> I don't understand the problem you see here - please fix it as you
> find appropriate.

I think we should still expose __clone() under _NETBSD_SOURCE, but
expose clone() only under _GNU_SOURCE.  My original reply that
prompted your patch was not very clear about this, but it talked
specifically about clone() (and clone() only).

Your patch hides both clone() and __clone() under _GNU_SOURCE.  You
were not forced to consider this choice b/c __clone() is not
implemented in C, so there's no C code in the tree that needs to see
the __clone() prototype that your patch hides.

__clone is in the reserved namespace, so no well behaving programs
should be affected by that declaration.

-uwe