public inbox for
 help / color / mirror / Atom feed
From: "Mike M. Volokhov" <>
To: Chad Walstrom <>
Subject: Re: Removing libiberty (was Re: gnatsd problems with 4.0.1)
Date: Wed, 09 Feb 2005 10:56:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]

On Mon, 7 Feb 2005 11:42:01 -0600
Chad Walstrom <> wrote:

> Mike M. Volokhov wrote:
> > 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.

What kind of troubles you have? Yes, there is a set of differences, but
I just wish to know a direction to handle them.

> > 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.

Exactly. The utils.[ch] possible the best place for handling this small
piece of software. Altough, I have rewrite some functions from scratch
and thus it can be joined the misc.[ch] files.

Please take a look to my patch which eliminates "libiberty" and
"include" directories completely. To test it:

1) Please be sure you have yesterday's AnonCVS sources.
2) Save the attached compressed diff to gnats subdirectory.
3) Apply a patch saved:
	gunzip < gnats-wo-libiberty.diff.gz | patch
4) Rename or remove "libiberty" and "include" subdirectories.
5) Configure and install GNATS as usual.

The following files was changed:
	gnats/ansidecl.h (moved from include/ansidecl.h)
	gnats/util.h (added)
	gnats/util.c (added)
	libiberty/* (all removed)
	include/* (all removed)

The following functions was rewritten from scratch and was based on
their respective standard equivalents:


The following functions should be shipped by 3rd-party vendors and thus
configure will rely on them (yes, I've dropped them from GNATS):


The xstrndup() function was changed to more fault-tolerant behaviour,
when passed length is less than 1. This fixes potential problems with
other functions which relies on xstrndup(), i.e.:

	strlen(xstrndup(string, 0))

I did some tests on my NetBSD 2.x and have not any visible troubles.


[-- Attachment #2: gnats-wo-libiberty.diff.gz --]
[-- Type: application/octet-stream, Size: 9055 bytes --]

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

Help-gnats mailing list

  reply	other threads:[~2005-02-09 10:56 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
2005-02-09 10:56           ` Mike M. Volokhov [this message]
     [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).