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: