>Number:         4478
>Category:       lib
>Synopsis:       libedit's namespace protection practices are funky/annoying
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people (Library Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 12 21:05:01 1997
>Last-Modified:
>Originator:     Jason R Thorpe
>Organization:
Numerical Aerospace Simulation Facility - NASA Ames
>Release:        source trunk of Wed Nov 12 20:49:26 PST 1997
>Environment:
	
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


>Description:
	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...

>How-To-Repeat:
	Try to build in e.g. src/usr.bin/ftp, and watch it fail with
	an unresolved reference to term_beep().

>Fix:
	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
		    bloat).

		(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.
>Audit-Trail:
>Unformatted: