`Hiding' libc symbols

[Harti Brandt]

On Tue, 6 May 2003, Jacques A. Vidrine wrote:

JAV>On Tue, May 06, 2003 at 09:56:06AM +0200, Harti Brandt wrote:
JAV>> There is no guarantee that you 'fix' the port by hiding the symbol.  You
JAV>> may as well break it. This depends on the function itself and on the
JAV>> internal relationships in libc. You have to go through each individual
JAV>> port and see what happens anyway.
JAV>
JAV>Please explain.  I _am_ guaranteed that keeping the port from hijacking
JAV>strlcpy calls in libc will not break the port.  How could the port rely
JAV>on the internals of libc?

Well, strlcpy is not a very interesting example because it stand on its
own. More interesting are examples where library functions depend on each
other (malloc/free, fopen and co.) The user calls its own malloc(), the
library tries to free with its own free().

The application could replace *printf() to actually redirect output...

At the end the port might have its own strlcpy to track buffers it has
written to for whatever reason.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org