Date: Sat, 5 Dec 1998 12:19:21 -0500
Message-Id: <199812051719.MAA30925@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <36696383.3E66693A@cyberoptics.com> (message from Eric Rudd on
	Sat, 05 Dec 1998 10:46:59 -0600)
Subject: Re: libc math function upgrade work
References: <199810191414 DOT KAA25670 AT indy DOT delorie DOT com> <36696383 DOT 3E66693A AT cyberoptics DOT com>
Reply-To: djgpp-workers AT delorie DOT com


> It seems to me that the issue is not so much the library routine polluting
> the ANSI namespace (since the global name "pow2" still exists in the stub)

No, it's exactly this.  The pollution happens if an ANSI function
(like fopen) uses a non-ANSI function (like open).  A program written
to expect ANSI might call fopen() yet have its own function open()
that does something completely unrelated (say, indicate that a door is
open).  ANSI says they *can* expect that.

Thus, if you put both labels on the internal open function (both
_open: and ___open:), then any DJGPP ANSI function calling __open()
makes it impossible for the user's program to have a function called
open(), even though the ANSI spec says they can.

So, the rule is this: ANSI functions may not, directly or indirectly,
call (or cause to be linked) any function (or other global symbol)
whose name isn't allowed by the ANSI spec.  POSIX functions may not,
directly or indirectly, call (or cause to be linked) any function (or
other global symbol) whose name isn't allowed by either the ANSI nor
POSIX specs.