`Hiding' libc symbols

[Valentin Nechayev]

 Tue, May 06, 2003 at 10:36:41, nectar wrote about "Re: Re: `Hiding' libc symbols": 

> Renaming the internal implementation of `foo' to `_foo', and creating
> a weak symbol alias with the original name (`foo').  Within libc,
> use the `_foo' name when the semantics must be known (e.g. when the
> behavior must not be overridden by an application accidently, i.e.
> almost always).  Macros in `namespace.h' help the compiler with
> prototypes etc.

OK. How will you distinguish accidental replacing of libc symbols
from intentional replacing? It is not reasonable (just IMHO) to divide
libc symbols into `allowed to override' and 'disallowed to override'
groups.
Well, one can say: if, e.g., application exposes Posix accordance,
it should not see strlcpy() (let's continue to use it as example) from libc.
So, define _strlcpy if not _POSIX_SOURCE of analog. Well, consider next Posix
will include it. Define non-hidden version and break compatibility of old
applications?
If I don't understand something, please explain.
But I think now is standards@ issue.


-netch-