Re: forget *documenting* libiberty -- how about *installing* it?

[Phil Edwards <pedwards at disaster dot jaj dot com>]

[Geoff, did you mean for that to go to gcc-patches?  I'm switching it back to
gcc with this response.  (I'll see your to: and raise you a followup.  :-) ]


On Thu, Jan 04, 2001 at 01:26:20AM -0800, Geoff Keating wrote:
> Phil Edwards <pedwards@disaster.jaj.com> writes:
> 
> > I'm not concerned about the "makeup" functions like strncmp and friends;
> > those should be declared by the user in one form or another.
> > 
> > But things like obstacks, hashtab, all of the x* functions, etc, should be
> > declared only by including the proper header file, which the user would
> > have to dig out of GCC sources and then hope that there's no mismatch
> > between gcc/include/* and whatever installed libiberty.a is on the system.
> > Or dig out all of libiberty and build a fresh version, Just In Case.
> 
> The original point of libiberty was that it's included with the
> packages that use it.

I haven't seen that many packages use it, is all.  I submit that more
packages would use it if it were already installed.

Alternatively, the "how to use" instructions could start off with "unpack
the sources into your code" rather than "install this if it isn't already,"
but all the other feedback I've gotten so far[*] has been in favor of
installation.

[*] all of 4 messages...


> It's intended to supply features like obstacks,
> strncmp, and so on, that the GNU system provides (in glibc) but that
> other systems might not.  I realize that it seems to have added
> hashtables and the demangler and a few other things that aren't
> present in glibc, but these are not the typical case.

Yeah, I was kind of surprised to see the demangler in there myself,
but hey.  :-)


> One nice consequence of this is that it isn't necessary to document
> all the functions that libiberty provides it its manual;

It has a manual?  Where?  I'd hate to duplicate work.


> you can just
> refer to the functions' definitions in the glibc manual.

Here's where we disagree.  This assumes that the user in question has
the glibc manual easily available.  I don't think most users of libiberty
would; after all, they are presumably not on a Linux system (that's why
they're using libiberty).  I myself have never seen the glibc manual;
there's nothing on either of the glibc homepages.  If somebody asked me
how to use obstacks, to this day all I can do is gibber a little while
and point them to the source.  :-(


> Another thing it does is provide wrappers around system functions,
> like 'xmalloc'.  These do need documentation, but by definition should
> not be installed anywhere standard as the wrappers may need to do
> different things in different programs; interactive programs should
> recover gracefully from malloc failing, for instance.

Those functions, IMHO, should be made more flexible.  (And I'm willing to
do the work.)  Right now, to recover from an xmalloc failure, somebody has
to rewrite chunks of xmalloc.c, for instance, instead of just installing a
"malloc handler".

I don't think needing to do different things in different programs should
preclude installing those routines (again, nowhere that they'd shadow
standard stuff, just someplace like <libiberty/libiberty.h>).  It just
means we need to make those routines open to user hooks.


> After all, if
> they should be installed, then they should probably be provided by
> glibc too.

Okay, say that they /are/ provided by glibc.  I'm using libiberty because
I'm not using glibc.  How does that help me?  :-)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.