`Hiding' libc symbols

[Dag-Erling Smorgrav]

Valentin Nechayev <netch at lucky.net> writes:
> Tue, May 06, 2003 at 04:23:48, des wrote about "Re: `Hiding' libc symbols": 
> > And I think you just don't understand the issue, and should leave it
> > to those who do while you take time off to read ISO/IEC 9899:1990.
> Can you please say some extraction from it for those poor guys not having
> got this standard?

The standard reserves a number of names and namespaces for the
implementation while others are reserved for the application.  We (as
an implementation vendor) regularly trespass into the application
namespace, and applications regularly trespass into the implementation
namespace.  Those are facts of life.  There are a couple of things we
need to take care of to avoid serious breakage:

 - The implementation (libc) must yield to the application in areas
   where it trespasses into the application namespace.  The linker
   handles that since libc is always last on the linker command line.

 - To the extent that libc relies on symbols in the application
   namespace which it defines itself, it must behave as if it didn't
   (because those names belong to the application) meaning that it
   must ensure that it uses its own versions of those symbols and not
   the application's.  This is handled partly by namespace.h.

 - The implementation must also guard itself against applications
   which incorrectly define names in the implementation namespace,
   because there are just too many of them to realistically expect
   fixing them all.  Moreover, I strongly believe that it is our task
   as implementation vendors to ensure that our implementation is as
   robust as possible in the face of non-conforming applications.

 - One important caveat is that (most) reserved names that do not
   begin with an underscore are reserved only when the header in which
   the standard requires them to be defined is included.  This is one
   of the reasons why I advocate building world with -fno-builtin; gcc
   incorrectly reserves names for builtin functions even when the
   standard mandates that these names are in the application
   namespace.  For instance, math functions such as sin(3) and cos(3)
   should not be defined unless <math.h> is included, but gcc always
   defines them, thus breaking applications which use these names
   themselves (sin is a popular name for sockaddr_in structs)

   (another reason for using -fno-builtin is that gcc's builtins hide
   bugs, especially those related to missing headers)

 - If you stayed awake through the previous paragraph you should by
   now have concluded that it simply is not possible for the linker to
   enforce namespaces like Andrey wants it to, because a) the linker
   can't know what headers were included; b) the exact set of reserved
   names can vary from compilation unit to compilation unit within the
   same application and c) namespace issues affect portions of the
   code which are outside the linker's purview (such as the names of
   function arguments and static or automatic variables).  Namespaces
   are a source code issue and cannot be handled anywhere but at the
   source code level.

 - 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.  In the case of ElectricFence, this means
   adding _malloc, _calloc etc. as aliases for malloc, calloc etc.;
   boehm-gc is not an issue because we don't configure it with
   --enable-redirect-malloc.

DES
-- 
Dag-Erling Smorgrav - des at ofug.org