`Hiding' libc symbols

Dag-Erling Smorgrav des at ofug.org
Tue May 6 12:39:56 PDT 2003


"Andrey A. Chernov" <ache at nagual.pp.ru> writes:
> On Tue, May 06, 2003 at 20:40:35 +0200, Dag-Erling Smorgrav wrote:
> > I would like to draw your attention to points b) and c) above and ask
> > how you plan to address them.
> About b), I don't quite understand, what you mean. If inside the same
> application some file includes, say, math.h and use sin() and another file
> not includes math.h and defines its own sin() it is error.

No.  It will lead to surprising results if the file that includes
<math.h> really does use sin(), but if it doesn't there is no reason
why the other file can not define an external symbol named sin because
sin is in the application namespace in that file.

> About c), at this moment we discuss functions namespace only, i.e. linker 
> "T" class.

So you admit that your solution is incomplete?  In that case, why do
you insist that it is superior to Jacques Vidrine's solution, which
addresses all cases without requiring us take the linker off the
vendor branch and make it unusable for non-hosted applications?

DES
-- 
Dag-Erling Smorgrav - des at ofug.org


More information about the freebsd-arch mailing list