`Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)

[Daniel Eischen]

On Thu, 1 May 2003, Andrey A. Chernov wrote:

> On Thu, May 01, 2003 at 11:34:57 -0400, Daniel Eischen wrote:
> > 
> > Wrong.  We need _ tricks for threads libraries to work properly and
> > was the reason it was added in the first place.  BDE came up with
> > the idea and it was reviewed by him.
> 
> Threads is completely another issue. We can do ANY tricks threads needs
> when it is NOT affects normal linking (under "normal" I mean preventing
> standard namespace replacement from outside of libc). If current
> replacement way for threads not allows preventing, it should be changed
> somehow to be truely libc internal, i.e. not explotable from outside of
> libc/libc_r/other threads libs.

I'm not sure what you mean, but what we have works well.  There
may be times that we want to call the internal _foo() and other
times were we want to call foo().  How are you going to build
a tool that can tell the difference if you reference foo() in both
places?

IMHO, I don't think we should make libc developers dumb so that
they don't have to know whether they should use foo() or _foo().
It's also easier to know which one is being referenced when you
are reading the source.

-- 
Dan Eischen