[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problem in library code using library functions
From: |
Paolo Faraboschi |
Subject: |
Problem in library code using library functions |
Date: |
Mon, 5 Feb 2001 17:15:14 -0500 |
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
- Problem in library code using library functions,
Paolo Faraboschi <=