public inbox for
 help / color / mirror / Atom feed
From: Chad Walstrom <>
Subject: Removing libiberty (was Re: gnatsd problems with 4.0.1)
Date: Mon, 07 Feb 2005 17:45:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1.1: Type: text/plain, Size: 2257 bytes --]

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 <> 
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

Help-gnats mailing list

  parent reply	other threads:[~2005-02-07 17:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-05 18:23 gnatsd problems with 4.0.1 Tim Buck
2005-01-05 22:24 ` Chad Walstrom
2005-01-06  9:18   ` Mike M. Volokhov
2005-01-06 17:07     ` Chad Walstrom
2005-02-07 15:47       ` Mike M. Volokhov
2005-02-07 17:15         ` Mark D. Baushke
2005-02-07 19:17           ` Chad Walstrom
2005-02-09 12:50           ` Removing libiberty (was Re: gnatsd problems with 4.0.1) Mike M. Volokhov
2005-02-09 17:15             ` Mark D. Baushke
2005-02-07 17:45         ` Chad Walstrom [this message]
2005-02-09 10:56           ` Mike M. Volokhov
     [not found]             ` <>
     [not found]               ` <>
2005-02-24 22:17                 ` Soon to come: RC3 Chad Walstrom
2005-02-24 22:40                   ` RC2 (was Re: Soon to come: RC3) Chad Walstrom
2005-01-06 16:03   ` gnatsd problems with 4.0.1 Tim Buck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).