`Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)

[Jacques A. Vidrine]

[Trimmed cc:list;  moving to freebsd-arch]


First, has something been broken by making strlcpy/strlcat into a weak
reference?


Second, for the sake of discussion only, let us assume that (a)
we like users, and we want users to use FreeBSD; and (b) we like
developers, and we want developers to write software on FreeBSD.

Then, let's consider an exercise.  Take two software packages:
 
  Package X defines a function named `strlcpy', that works well for
  Package X and may or may not have any relationship to the `strlcpy'
  we all know and love from OpenBSD.

  Package Y utilizes strlcpy.  It does not define it, but makes the
  fairly reasonable assumption that the platform provides a working
  strlcpy with the (now) well-known semantics from OpenBSD.

Which of the following scenarios is the least astonishing?

  Scenario 1.  Package X builds and runs, but blows up in certain
  libc functions.  Package Y builds and runs correctly.

  Scenario 2.  Package X builds and runs correctly.  Package Y
  builds, but only if you link it with the rather non-standard
  `libkitchen_sink'.  The image of Package Y is also bigger than
  on other platforms, because it has two implementations of strlcpy
  (the one used internally in libc, and the one from libkitchen_sink).

  Scenario 3.  Package X and Package Y both build and run correctly.

Guess which scenario applied before my commit to make strlcpy/strlcat
weak references? which applies now? which would apply if we broke
strlcpy/strlcat into another library?

For bonus points, extend the example with Package Z, which uses
`strlcpy' but only defines it if it doesn't detect it as implemented
on the platform.  Maybe multiply the instances of applications such as
Package X, Y, and Z by 8000 or so --- how does that affect the issue?


Third, specific comments below if you are not bored yet.

On Wed, Apr 30, 2003 at 04:36:45PM +0100, Paul Richards wrote:
> On Wed, Apr 30, 2003 at 10:27:08AM -0500, Jacques A. Vidrine wrote:
> > 
> > We have no business exporting symbols from libc that are not described
> > by any standard.  We have no business assuming that if an application
> > defines a function called `strlcpy' that it resembles, in intent or in
> > actual implementation, our own strlcpy.
> 
> That's an orthogonal issue really, since libc is not a "pure"
> implementation of the standard C library, it also includes a number of
> extensions that have been bundled into our libc because it's sometimes
> a convenient dumping ground.

I don't see how you can call that `orthogonal'... that is the root of
the issue we are discussing.

> Hiding functions that aren't meant to be exported would make sense,
> but hiding functions that are intended to be exported but aren't
> part of the standard is not so useful.

How is it not useful?   It is useful for qpopper.  It is useful for
isc-dhcp.

> strlcpy is part of the "FreeBSD libc" since it's a documented interface
> for application writers to use.

<sarcasm degree="a-bit-over-the-top">
Oh, of course.  I forgot that we only support applications written for
FreeBSD.  I thought we should be a decent platform for ISO C and POSIX
applications as well, but that is clearly foolishness.
</sarcasm>

> The alternative is to split out these functions and keep libc pure, and
> then link them into our applications if we use them. This is an approach
> other platforms have taken but one we've not gone down because of the
> proliferation of libraries that then have to be included when writing
> apps.

What are these other platforms?  Could you elaborate on what exactly
they are doing that you think we should emulate?  There are platforms
with `strlcpy' in the base system, but not in libc?  There are platforms
that have _no_ functions in libc that are not in ISO C?  in POSIX?
If we were to decide to make such a split, what functions would be OK
for libc?  Which standard will we take as authoritative?  Only ISO C
functions?  Only POSIX functions?  Which options in POSIX? etc


On Wed, Apr 30, 2003 at 11:49:36AM -0400, W. Josephson wrote:
> On Wed, Apr 30, 2003 at 10:27:08AM -0500, Jacques A. Vidrine wrote:
> > We have no business exporting symbols from libc that are not described
> > by any standard.  We have no business assuming that if an application
> > defines a function called `strlcpy' that it resembles, in intent or in
> > actual implementation, our own strlcpy.
> 
> Then we should not export functions used internally that aren't
> a part of the standards at all and put functions such as strlcpy
> that are explicitly exported by design in a different library, no?

No, I don't think so.

1) We break the build of many applications if we move commonly-
   used interface into some new library.

2) We add an annoying difference with other platforms that also
   implement these commonly-used interfaces.

3) We add code bloat.  These commonly-used interfaces are used within
   libc and within applications.  If we split them out into separate
   libraries, then applications will carry around twice the code.

> > return value from our strlcpy.  Is it a bug in that application if it
> > cannot use parts of libc because of this?  No.  It is a bug in our
> > libc.
> 
> I think this is a separate issue from what gave rise to the
> discussion.  

What is a separate issue?  This is _the_ issue.

> I still believe it is a mistake to play games with
> symbols explicitly exported by libc.  Either the symbols should be
> exported normally or they shouldn't be exported at all: 

Think through the consequences of this. e.g. If we did not export
`warn' using a weak reference, then dhclient could not be compiled
statically on FreeBSD.  If we did not export `warn' at all, then we
would need to put `warn' in a separate library and break lots of code.

> keeping track
> of which platform does what with which functions, be they standard
> functions or common extensions, just makes life harder for everyone as
> far as I can tell.

But that is what it sounds like you are suggesting.  ``Oh, I forgot,
to use strlcpy on FreeBSD, I must add `-lfreebsd', how lame.''


Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME      . FreeBSD UNIX       . Heimdal
nectar at celabo.org . jvidrine at verio.net . nectar at freebsd.org . nectar at kth.se