Subject: lib/2096: end is in user namespace.
To: None <gnats-bugs@NetBSD.ORG>
From: Peter Seebach <seebs@taniemarie.solon.com>
List: netbsd-bugs
Date: 02/18/1996 11:48:09
>Number:         2096
>Category:       lib
>Synopsis:       end is in user namespace; programs using externs called end die.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people (Library Bug People)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 18 13:50:01 1996
>Last-Modified:
>Originator:     Peter Seebach
>Organization:
Usenet Fact Police (Undercover)
>Release:        2-16-96
>Environment:
System: NetBSD taniemarie 1.1A NetBSD 1.1A (SEEBS) #0: Mon Jan 15 20:07:46 CST 1996 seebs@taniemarie:/usr/src/sys/arch/amiga/compile/SEEBS amiga

>Description:
	The external symbol "end" is in the user's namespace, so a perfectly
	legitimate user program can acquire memory faults for using that
	name.
>How-To-Repeat:

	Compile these two code fragments together:
	---
	extern void end(void);
	main() { end(); return 0; }
	---
	void end(void) { return; }
	---
>Fix:
	I dunno; how much software depends on and needs end?  IMHO, end,
	etext, etc. should probably be moved into the library name space,
	and/or linking should ignore them until all user provided routines
	and names are linked.

	No idea where this is on POSIX conformance.  Obviously, ANSI
	prohibits this behavior.  (Actually, it doesn't; ANSI basically
	loses all power when you have a program in 2 translation units,
	and this works fine if end is defined and used only within one
	translation unit.  But it *intends* to prohibit use of the
	user namespace.)
>Audit-Trail:
>Unformatted: