Size of libinn (was: Re: INNT overview..)

Russ Allbery rra at
Thu Jun 21 10:25:10 UTC 2001

Whew, now with that over with or at least well-started, I can get back to
some other INN stuff and old mail.  :)

Fabien Tassin <fta at> writes:
> According to Russ Allbery:
>> Fabien Tassin <fta at> writes:

>>> I don't like libinn in its current form. I really would like to see 
>>> smaller libs with dedicated sets of tasks.

>> Could you let me know what about it you don't like in particular?  I'd
>> really like to clean up libinn as much as I can; there are parts of it
>> (sometimes large parts) that I haven't gotten to yet, but I think most
>> of the new stuff that's been put in or cleaned up is pretty solid and
>> generally useful.

> It is mainly a size problem.

> -r-xr-xr-x    1 news     news      1236736 Mar  7 00:11 libinn.a
> -r-xr-xr-x    1 news     news       692554 Mar  7 00:11 libstorage.a

> the threading problem is also easier to avoid/fix with much smaller libs.

Much of the size problem is relatively localized, actually:

windlord:~/dvl/inn/lib> ls -lrS *.o | tail -15
-rw-r--r--   1 eagle    root         4528 Jun 21 03:14 vector.o
-rw-r--r--   1 eagle    root         4552 Jun 21 03:14 wildmat.o
-rw-r--r--   1 eagle    root         4768 Jun 21 03:14 getmodaddr.o
-rw-r--r--   1 eagle    root         5292 Jun 21 03:14 error.o
-rw-r--r--   1 eagle    root         5656 Jun 21 03:14 date.o
-rw-r--r--   1 eagle    root         5996 Jun 21 03:14 timer.o
-rw-r--r--   1 eagle    root         6048 Jun 21 03:14 hashtab.o
-rw-r--r--   1 eagle    root         8440 Jun 21 03:14 inndcomm.o
-rw-r--r--   1 eagle    root        12080 Jun 21 03:14 md5.o
-rw-r--r--   1 eagle    root        12136 Jun 21 03:13 snprintf.o
-rw-r--r--   1 eagle    root        15528 Jun 21 03:14 dbz.o
-rw-r--r--   1 eagle    root        17668 Jun 21 03:14 perl.o
-rw-r--r--   1 eagle    root        18700 Jun 21 03:14 confparse.o
-rw-r--r--   1 eagle    root        22608 Jun 21 03:14 parsedate.o
-rw-r--r--   1 eagle    root        79892 Jun 21 03:14 getconfig.o

As you can see, far and away the worst offender is the current inn.conf
parsing code, in part because the current implementation involves code
duplication on a massive scale.  The new parsing code should be a
significant improvement there.

parsedate is the second-worst because yacc is a bloated hog.  I'm pretty
sure that there are better ways of doing date parsing that doesn't require
a full-blown parser, particularly since it's questionable whether we
really want to allow some of the stuff that parsedate allows through.

Of the rest, dbz is going to move into the history library once we land
that code, perl.o isn't included in libinn.a, snprintf isn't included if
you have a working version, and pretty much everything else other than the
configuration parsing code is noise.

It's true that a lot of it isn't thread-safe, but then again most of it
you'll never call.

>> How does it conflict with dmalloc?  Maybe I can help resolve the
>> conflict?  My intention was for xmalloc to be more generally useful
>> than even just in INN, and I have an interest in making sure it doesn't
>> have serious conflicts with other packages.

> dmalloc already uses xmalloc defines..

> dmalloc.h :

> #undef xmalloc
> #define xmalloc(size) \
>   _xmalloc_leap(__FILE__, __LINE__, size)
> #undef xcalloc
> #define xcalloc(count, size) \
>   _xcalloc_leap(__FILE__, __LINE__, count, size)
> ....

What's wrong with that?  Provided that you include dmalloc.h last as it
recommends, it will just undefine and redefine the xmalloc, xcalloc,
etc. functions and use dmalloc's error handling for allocation failures
rather than INN's.  Given that this is for doing debugging, that doesn't
seem like it would cause any harm.

Russ Allbery (rra at             <>

More information about the inn-workers mailing list