`Hiding' libc symbols

[Harti Brandt]

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

JAV>On Tue, May 06, 2003 at 05:59:21PM +0200, Harti Brandt wrote:
JAV>> Please! I know what I'm talking about. I have been hit by the broken
JAV>> shared library design in BSD/OS and I have been hit by all those
JAV>> non-standard functions with names that each application writer loves to
JAV>> use in our libc (err for example), but I have also on occasions replace
JAV>> exit with abort to find a very obscure bug, I sometimes use a debugging
JAV>> libmalloc, I know libraries that replace str* functions to find bound
JAV>> errors.
JAV>
JAV>You have yet to indicate how hiding some additional symbols in libc,
JAV>using the method that we already have, will cause this hair loss to
JAV>which you are referring.  You can certainly replace `exit' with `abort'
JAV>now if you want.  As a matter of fact, `exit' is already `hidden' for
JAV>a few years, and I haven't seen you complain earlier.

Well that may be some years ago actually, when I also decided to rename
the err() function in my PDP-11 emulator :-( With exit() the situation
actually seems a little bit more complex, because there is already an
_exit() with different semantics.

JAV>> I'm just telling that simply hiding all symbols without caring of what
JAV>> that may cause is certainly wrong.
JAV>
JAV>I concede that might be the case.  It seems clear that hiding the
JAV>allocators might be of questionable use.  Anything else?

Watch out for Schilling's programs (star, cdrecord). And other programs
that use to carry half of libc around.

JAV>> And stating that this will
JAV>> automagically make buggy ports un-buggier is also wrong.
JAV>
JAV>Well, we've already had at least one port where it most certainly
JAV>made a difference.  The issue is one of safety and robustness ...
JAV>we should not be calling into application's functions _on accident_.

Actually fixing the problem at the source would be even better.

JAV>> Go ahead with non-standard functions, but make sure that you don't break
JAV>> ports when doing this with standard functions.
JAV>
JAV>Quick question:  is strlcpy a standard function, or a non-standard
JAV>function?  What else are standard functions?

All str* functions are in the implementation name space so any program
using a name starting with str is non-conforming. At the moment I cannot
start my acroread or I would point you at the corresponding paragraph in
ISO-C. Add posix to this.

JAV>Many `standard' functions are already hidden.  I don't expect much, if
JAV>any, breakage, but testing against the port cluster would be advisable
JAV>before committing en masse.

Hmm. That means you ensure that the program compiles and links, not that
it runs.

A question that just occured to me is: how is one expected to find out via
autoconf, whether to use a _ in front of the questionable function or not?
It will compile and link without a warning in either case and provoking a
run-time error may actually not be simple.

JAV>Actually, even if we had consensus to go this route, I'm not sure that
JAV>one would want to do it en masse?

I have no clue how to do it except do it and watch out for people to
complain.

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