`Hiding' libc symbols

[Valentin Nechayev]

 Tue, May 06, 2003 at 19:56:27, des (Dag-Erling Smorgrav) wrote about "Re: `Hiding' libc symbols": 

>  - Applications which rely on overriding parts of the implementation
>    are non-conforming and cannot claim a "moral right" to do so.  In
>    the few cases where applications have good and useful reasons for
>    overriding parts of the implementation, they can easily be modified
>    to cope with whatever techniques the implementation uses to avoid
>    namespace collisions.

OK, this is possibly the main discussion stone. If application wants
to override some library function, a mechanism to do it should exist
(in any case application can get function address and install machine
jump command to its, so it is not desirable to make unreasonable barriers;))
But this mechanism should be used explicitly, if policy requires.

Thanks for good clarification.

> The standard reserves a number of names and namespaces for the
> implementation while others are reserved for the application.  We (as

<offtopic> Hmm, the first thing I want to see in C is namespaces, similar
to C++ ones or better.</offtopic>

>    Namespaces
>    are a source code issue and cannot be handled anywhere but at the
>    source code level.

I thought identically but hadn't enough words to say it.
But what form of source code level support should be used? Some namespaces
are defined using Posix|X/Open|SUS macros, but too few applications use it
and properly define restriction macros in their sources; moreover,
average open-source application is written with requesting of maximal
namespace importing (as #define _GNU_SOURCE for GNU libc headers).
C header file traditions adds its own hell: one can't include <string.h>
without strlcpy() not defining Posix restrictions, and there is no
/usr/include/string/strlcpy.h which defines only it and size_t for
its prototype;( Continuing this style, one can't separate declarations
in subsets (Posix subset, SUS subset, BSD subset...) and the same problems
will continue. (This wasn't positive position, but too skeptic...)


-netch-