Subject: lib/4478: libedit's namespace protection practices are funky/annoying
To: None <email@example.com>
From: Jason R Thorpe <firstname.lastname@example.org>
Date: 11/12/1997 21:03:45
>Synopsis: libedit's namespace protection practices are funky/annoying
>Responsible: lib-bug-people (Library Bug People)
>Arrival-Date: Wed Nov 12 21:05:01 1997
>Originator: Jason R Thorpe
Numerical Aerospace Simulation Facility - NASA Ames
>Release: source trunk of Wed Nov 12 20:49:26 PST 1997
System: NetBSD lestat 1.3A NetBSD 1.3A (LESTAT) #110: Tue Oct 28 18:45:38 PST 1997 thorpej@lestat:/tmp_mnt/dracul/u5/netbsd/src/sys/arch/sparc/compile/LESTAT sparc
libedit's Makefile builds a source file called editline.c,
which static'izes a whole slew of functions in .c files included
by editline.c. This not only protects the user's namespace,
but also protects the internals of libedit from braindead
programmers who like to use non-public functions.
This does, however, have an annoying `feature'. If an object
in libedit wants to call any of these protected functions, it
must be included in the monolithic editline.o object.
One such object is readline.o, libedit's readline emulation
facility. It wants to call term_beep(), a protected function
of term.c. However, readline.o is included as a standard
library object, not in the monolithic editline.o. This causes
unresolved references to term_beep() if a program is dynamically
linked against libedit with a modern linker (e.g. the GNU binutils
Elf linker used by NetBSD/alpha). Note this problem is noticed
when the program is built, not during the run-time link.
Why this problem is not noticed by NetBSD's a.out toolchain is a
mystery to me, and I'm really not sure I want to know...
Try to build in e.g. src/usr.bin/ftp, and watch it fail with
an unresolved reference to term_beep().
I have committed a workaround to libedit which addresses this
specific problem of readline.o wanting to call term_beep(). My
workaround is to un-static'ize term_beep() and use the CPP to
rename it to __term_beep() to keep it out of the user's namespace.
This is not a good general solution, however.
I can see two possible solutions:
(a) Include readline emulation in the monolithic
editline.o. This has the problem of always
including readline emulation symbols and functions,
which may not be desirable (namespace pollution and
(b) Use a more standard namespace protection scheme,
such as that employed by libc. Namely, protected
functions get "__" prepended to their names, and
are not static. This exposes the internals of
libedit, however, which may not be desirable.
Because both solutions have downsides, I'm not going to attack
it now. This PR exists to note the problem so that someone
else can deal with it.