Re: Call for help on improving the documentation

[Greg A. Woods]

[ On , September 22, 2000 at 14:19:51 (-0700), Russ Allbery wrote: ]
> Subject: Re: Call for help on improving the documentation
>
> Interesting; I wasn't aware those functions existed.  (INN does its own
> bit fiddling.)  Where are they available again?  They're not in BSDI 3.1,
> and I've not seen them on Linux or any of the normal commercial Unixes.

The inet_net_?to?() functions are in every system that uses any BIND
resolver newer than or including BIND 4.9.4 (which was released sometime
in late 1996 IIRC).  386BSD and all the *BSDs that followed (including
BSDI's reimplementation) don't have these functions unless they've
upgraded their resolver library, because they all started out with the
much older resolver from 4.3BSD-Net2 (I suspect it was basically
equivalent to the one from BIND-4.9.2 or earlier).  NetBSD, for example,
didn't pick these functions up until NetBSD-1.3 though (which wasn't all
that long after they were released, but still longer than was necessary).

> I can see your point for mail servers, as they do quite a few more DNS
> queries, but news servers really don't do anything at all exciting with
> DNS.

That's true unless you've got posters in many networks or you exchange
some local hierarchy with servers worldwide....

> I'm curious as to exactly what those bugs are, yes, and what they affect.
> (Stuff related to weird records I generally don't care about.  Stuff that
> only affects Solaris's name server I also don't care about, as we never
> run it; we're using dnscache most places now, and where we aren't we're
> using BIND 8.  I'm aware that Solaris's nscd has a broken notion of TTLs,
> but in practice it almost never causes problems.)

Most of the problems that I can still remember are related to error
handling and change mangement (and indeed most of ncsd's problems are of
the latter kind, though it breaks negative caching worse than it breaks
TTLs).

> So from that perspective, what would be really helpful would be some way
> of detecting brokenness in the resolver library at configure time.

I doubt this is possible without resorting to associating detectable
features with bad behaviours in other parts of the library.  You'd
practically have to set up a remote DNS server and query it under
extenuating circumstances to tickle many of the bugs.

> That's part of what I hope we're changing a little with this thread and
> its results.  I've thought for a long time that it was a flaw in
> autoconf's documentation that it tells you what's wrong but often doesn't
> give you any hints on how to fix it.

But autoconf's documentation is, I'm hoping, supposed to be a manual on
how to use autoconf.  It's not really a complete dissertation on the
state of software portability in the universe despite the fact that it
hints at many of the common problems given the fact that it has tests to
detect them.

> Sun's quite capable of fixing the bugs themselves without also including
> newer BIND library functionality, though.

There have been rumours to this effect, but at least in some
circumstances it's fairly obvious that they've not actually fixed
anything despite changing something.  I've given up on trying to follow
Sun's antics in SunOS-5, but with SunOS-4 there were many clearly
obvious bugs (which today might even have been considered security bugs)
that were never fixed even when fixed versions of BIND's resolver were
available many months in advance and when in at least SunOS-4 it was
relatively painless to completely remplace the system resolver with the
latest BIND release except in statically linked binaries.  (I.e. there
were no hidden APIs, and no hidden hooks (eg. nsswitch.conf).)

The major problem here from an application programmer's perspective is
that private fixes to private versions of the BIND resolver lead to many
new unique bugs.  If Sun had simply re-written their own resolver from
scratch and used only a compatability layer for BIND's libresolv API
then at least the choice of direction in which to point one's finger
would be a bit more obvious.

> I'd at least like it to be clear in the documentation what vintage of
> systems are affected by a given problem.  For example, I see a lot of
> people using AC_FUNC_SETVBUF_REVERSED, and I find it really unlikely
> there's many, if any, people out there with pre-SysVr3 systems out there
> and that said software would work on those systems anyway.

One might try to conjure up fake examples but I doubt there have been
any for years now.  I decried that test even before autoconf was
invented because it was literally a bug in only a few releases of a very
few types of systems and it was fixed in almost all instances that I can
remember.

> (It's also somewhat depressing to see the number of packages that check
> for things like that but are completely unprepared to deal with the check
> failing.  There's no point in checking for something unless you have a
> solution for it or unless you intend to abort configure if you don't get
> the results that you want.)

Hmmm....   this is indeed a pressing problem!

> What would be *truly* valuable from my perspective would be some
> indication of when given headers showed up.  For example, INN is still
> faithfully checking for the existence of unistd.h and only including it
> conditionally, mostly because I'm not sure when unistd.h showed up.  I'm
> betting that we shouldn't bother with that check any more given that we
> already require that the system has fcntl.h, and the likelihood that a
> system has fcntl.h and not unistd.h is probably fairly remote, but I don't
> know for sure.

I've often been concerned about the opposite because, at least before
the wide dissemination of "open source" systems, people often made a lot
of local hacks to their systems in an attempt to rationalise them and
make them appear to be something that they were not originally (myself
included! :-).  For example some of the examples in the autoconf manual
worry me because they make assumptions about dichotomies which didn't
exist in some of the systems I created (not that breaking these
assumptions would usually cause any incorrect behaviour).

So in some respects I'm happier with individual feature tests and
conditional compilation....

> As a result, configure.in files tend to keep all their old portability
> bits that someone put in because they found it in the manual and everyone
> else is afraid to touch because they don't have access to any of the
> affected systems.  If we had something like "don't bother checking for any
> of the following if you don't care about systems prior to 1990," that
> would be wonderful.  I'm betting fcntl.h, unistd.h, the mem* functions,
> and getopt all fall into that category.

This would be good.

> example, I see software that uses ANSI C function prototypes but tests for
> varargs.h vs. stdarg.h and chooses the right variadic argument syntax
> accordingly.  Are there really ANSI C compilers that don't have stdarg.h?
> gcc appears to supply its own.

Not likely any modern ones, but there were some early adopters who
didn't shoot for full compliance (I'm not sure any were on Unix
though).

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>      <robohack!woods>
Planix, Inc. <address@hidden>; Secrets of the Weird <address@hidden>