[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Removing libiberty (was Re: gnatsd problems with 4.0.1)

From: Chad Walstrom
Subject: Removing libiberty (was Re: gnatsd problems with 4.0.1)
Date: Mon, 7 Feb 2005 11:42:01 -0600
User-agent: Mutt/1.5.6+20040907i

Mike M. Volokhov wrote:
> First, excuse me please for the delayed answer. :-(

No problem, we're all busy these days.  Work has been hectic and I
haven't been able to provide those two hours per week I had hoped.  By
the end of February, however, this should change and I'll once again be
able to spend more time on GNATS.

> Yes, that's exactly I've asked why. Including libiberty in GNATS
> codebase depends on how much it is used by the project.

Thanks for the audit, by the way.  Very nice work.

> Unfortunately, libiberty itself seems have not official distribution

In addition, there does not seem to be any plans to create an official

> I've done some sort of GNATS sources audit to know how much project
> dependends on libiberty code. Well, seems it is not too hard
> dependent!  I've used libiberty.h header file to obtain a list of
> provided functions and ran a simple script across gnats/*.[ch] files.
> It shows a results at the end of this mail message.

Again thanks!

> So, only six functions are used by GNATS, when libiberty provides
> about 40. Only two functions (asprintf and vasprintf) are nor POSIX
> nor standard C relevant (but included in both GNU and BSD libc).

Actually, add one more: getopt(), which is the one that's currently
giving us problems on the BSD platform.

> Three functions (xstrdup, xmalloc, xrealloc) are totally
> libiberty-own, but can be easy replaced with their standard
> equivalents.

Yes.  They're convenience functions documented in the glibc "standards"
manual as well.  In fact, writing wrapper functions is well documented
by the venerable Stevens in his Unix programming books, although I
believe he would have named the wrapper "Malloc()".  ;-) As such,
they're not bad little functions, but I agree that we shouldn't have to
carry libiberty around just for these three.

> Thus, I propose to eliminate dependency on libiberty completely.

I support that proposal.  When only 7 of 42 are required, they should be
relatively easy to move into misc.c or a utils.{c,h} file pair and
support in autoconf.

Chad Walstrom <address@hidden> 
           assert(expired(knowledge)); /* core dump */

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]