Problem in library code using library functions

[Paolo Faraboschi]

Here's a symptom of a problem that may be the proverbial "tip of the iceberg"...
The following seemingly innocuous code hits the assertion (using glibc-2.2 on a 
linux system):

        #include <assert.h>
        strrchr() { assert(0); }
        main() {}

The problem is caused by the fact that something in the init sequence of libc 
(set_progname() from assert.c in this specific case) calls strrchr(). Now, if I 
remember correctly what POSIX says, programs should be free to redefine the 
entry point of any function (ok, not level-1 OS calls). Libraries should only 
refer to secondary name definitions of whatever they need for themselves. This 
is clearly not true here. After a quick inspection, I have the impression that 
the polluted name space is actually quite large.

I don't think this will affect the user community at large, but may be an issue 
for people that want to redefine certain library functions for their own use.

Maybe it's worth adding this as a consideration for a future cleanup. It 
wouldn't be hard to fix, for example, by making sure of always using an '_' 
version of library functions when writing library code. The _ functions can be 
defined as a weak alias. BTW, many of these symbols already exist.

Regards,

-- Paolo Faraboschi
Hewlett-Packard Laboratories Cambridge
1 Main St. 10th floor
Cambridge, MA 02142