Re: Call for help on improving the documentation

[Russ Allbery]

Greg A Woods <address@hidden> writes:
> [ On , September 22, 2000 at 00:19:29 (-0700), Russ Allbery wrote: ]

>> I think you mean inet_ntop and inet_pton, the replacements for
>> inet_ntoa and inet_aton that can deal with IPv6 addresses?  The only
>> operating system that I've seen that has those is BSDI (and probably
>> other BSD varients); Solaris didn't add them as supported functions
>> until Solaris 8 if I remember right, and Linux glibc 2.1 doesn't seem
>> to have them.

> No, I definitely mean inet_net_ntop() and inet_net_pton().

Ah.  I've never seen those anywhere.

> Inet_pton(), for example, cannot be used to convert a CIDR-style network
> specification to an internal IP number whereas inet_net_pton() can
> convert a host representation (with or without the CIDR "/32" spec) to
> an internal IP number.  Applications that don't want to do their own
> parsers and bit-fiddling to allow a user to specify CIDR-style host and
> network numbers in access lists, etc., can use inet_net_?to?() to do the
> necessary conversions but not inet_pton().

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.

> If you want to run a news server or a mail server that interacts with
> the Internet as a whole (i.e. which needs true DNS support) you really
> cannot get by with any resolver library ever shipped by Sun.

Funny, I have been for years.  The news server was in the Freenix top 50.
The mail servers seem to be working fine.  :)

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.

> These problems are all very well documented in the archives of the
> various BIND and DNS related mailing lists and newsgroups and indeed the
> more recent BIND sources include descriptions of some of these bugs, as
> well as of course working code that does not suffer from these bugs.  If
> anyone wants to discuss these facts I'd welcome you to e-mail me
> privately or to join in on one of the BIND or DNS related forums.

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

> Well, yes, to the extent where it should be able to detect such broken
> systems, and/or at least know what they are.

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

> It is not autoconf's job to actually provide work-arounds -- that's left
> to the programmer.

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.

> With the resolver functions in particular there are not really any ways
> to concoct a test scenario within the confines of autoconf.

Yeah, I was afraid of that.

> You have to rely on knowing where the bugs exist based on the system
> type, or in detecting known buggy versions by looking for indicators
> such as the lack of hstrerror().

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

> Hmmm... yes, I've been wondering just how wise it is to keep autoconf in
> particular ready to deal with V7, 4.2BSD, SysVr2.2, and other true
> antiques.....

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.

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

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.

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.

It would also be interesting to know what things are tied together.  For
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.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>