Mail Archives: djgpp-workers/1998/12/05/11:46:55
DJ Delorie wrote:
> The stub mechanism allows ANSI functions to call non-ANSI functions
> without polluting the ANSI namespace. For example, some ANSI function
> might need to call pow2() for something, but pow2() isn't ANSI. The
> stub #defines pow2() to be __pow2() in stubs.h and provides a jump
> (stub*.s) for the old name. This way, when the ANSI function calls
> pow2() it's really calling __pow2(), but if a user program calls
> pow2() it really calls pow2(), which is the stub, which jumps to
> __pow2().
>
> However, if the user provides their own pow2() function that's
> different than ours (maybe it prints "pow!" twice), the ANSI function
> that wanted *our* pow2() will still work.
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)
as the desire to maintain internal access to a subroutine even if the user
has polluted the DJGPP namespace. However, I don't see why one couldn't
get rid of the stubs by simply having multiple labels in the subroutines:
.globl ___pow2, _pow2
___pow2:
_pow2:
...code
since this gets around the additional overhead of a jump.
There are several functions which have been renamed in C9x. For instance,
continuing with the above example, in C9x pow2() does exist, but is called
exp2(). Thus, I have placed an additional label in the pow2.S source,
like this:
.globl ___pow2, _exp2
___pow2:
_exp2:
...code
I don't think this will cause a problem, since existing routines can
continue to call pow2() by using the stub or the existing ___pow2 label.
However, new code should probably get on the C9x bandwagon and use exp2()
instead. If you see a problem with this methodology, please let me know.
Now, what should I do about math.h? For now, I have put the prototypes
for additional non-ANSI functions (including the aliases) in the #ifndef
__STRICT_ANSI__ section (near pow2(), etc.).
-Eric Rudd
- Raw text -