Upcoming lib changes for system library replacement functions

Russ Allbery rra at stanford.edu
Fri Jul 14 02:00:03 UTC 2000

For another project, I've been implementing a lot of the replacement
functions that INN also uses (lib/inet_ntoa.c, lib/memcmp.c, and so forth)
along with test suites for them.  I figure INN may as well benefit from
that work as well, so I'll be checking them into lib with coding style
tweaks to conform to INN's style.

For the most part, no one should care one way or another; most platforms
don't need these functions anyway since they're in the system libraries.
The only real advantage that my versions have over the ones that are
already there is that they come with a test suite and have been verified
to compile cleanly under a rather high warning level, plus I'm actively
maintaining them (not that they're likely to need it).  The main reason
why I reimplemented them for other projects rather than just using BSD
source is that for other projects I didn't want to carry around that huge
BSD license with everything; for INN, it doesn't really matter.

My replacements are in the public domain.

(My inet_aton does work on non-ASCII systems whereas the BSD version may
not, not that I expect anyone to actually care.)

The only function of any real complexity is inet_aton, and I've tested
that one pretty thoroughly.

Currently, when compiling INN on an IRIX platform using gcc, we suffer
(and have for quite some time) from the known problem with gcc on IRIX,
namely that inet_ntoa returns garbage.  This is due to a difference in the
ABI used by gcc vs. used by the IRIX system libraries for passing structs
on the stack.  I'll add a test to configure.in for this, and fall back on
our replacement inet_ntoa function in this case (which, since it's
compiled by the same compiler as the rest of gcc, should work fine).

The functions that will be affected are:

    inet_aton, inet_ntoa, memcmp, pread, pwrite, setenv

strerror was already switched to my version some time back.

INN currently also provides replacement functions for:

    memchr, memmove, memset, strcasecmp, strspn, strtok

Does anyone have any opinions on whether all of these are worth keeping
around?  I would be very surprised if anyone manages to run INN on a
system where those mem* functions are missing; we don't support 4.3BSD
anyway since we require mmap.  I guess they're not really hurting
anything, but if they're really dead code it might be worth cleaning them
out.  (strtok at least we should probably keep; I've personally
encountered systems that don't have it.)

I do plan on removing INN's strcasecmp man page unless there are any real
objections; we don't maintain man pages for any of the rest of our system
library replacement functions, and I'd rather not try to.  Plus that
simplifies configure a bit.

Finally, I'm going to remove INN's strdup replacement as soon as I clean
up innfeed and one part of innd to use xstrdup instead.  Nothing in INN
should be calling strdup directly; either xstrdup or COPY (which uses
xstrdup under the hood) should be used instead.

Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

More information about the inn-workers mailing list