> > At this point, isn't there far more software using SIOCGIFCONF
> > "incorrectly" than correctly? And if this is the case, shouldn't
> > the program for which the behavior was "fixed" (racoon, IIRC) be
> > modified instead?
> 
> No, and no (though given the form of the conditional, I suppose perhaps
> "yes" is just as good an answer).  The original change to the ioctl was
> to fix an overrun/truncation problem.  It turned out that some broken
> programs relied on the buggy behavior, but many do not, and in any
> case we cannot put it back how it was.  Greg has analyzed this in more
> detail than anyone could reasonably expect; have you read his other
> messages on the subject?

Actually, I have. To recap:

On 30 aug 2007, gdt posts to tech-net, <rmiveax9g62.fsf@fnord.ir.bbn.com>:

  racoon doesn't work in current because SIOCGIFCONF is broken. (I know
  racoon should probably not use SIOCGIFCONF, but instead getifaddrs.  I
  won't argue, but SIOCGIFCONF should work in any case.)

More analysis of how the ioctl is purportedly broken is in that message.
However, the root cause of such breakage seems to come from the addition
of some fields to struct ifreq in late May/early June. AFAICT, no other
programs using SIOCGIFCONF broke due to those changes.

On 11 Sep 2007, gdt checks in -r1.200 of src/sys/net/if.c with his fix(es).

On 12 Sep 2007, Patrick Welch mails current-users about dhcpd not working.
(viz <20070912144453.GA1070@quartz.itdept.newn.cam.ac.uk>)

Later, that same day, gdt provides an analysis of what's happening in
<rmi8x7b78el.fsf@fnord.ir.bbn.com>; he notes that much of this comes
down to the API for the ioctl, and deems one possible interpretation
to be 'crazy' (and in a different message, his interpretation to be
'sane'.) 

On 13 Sep 2007, gdt checks in a fix to dhcp's discover.c

On 31 Sep 2007, in <rmi3avrmoxo.fsf@fnord.ir.bbn.com>, gdt analyzes
even more problems in dhcpd related to SIOCGIFCONF.

On 31 Oct 31, gdt checks in yet another fix to dhcp's discover.c

On 8 Nov 2007, smb reports that nmap ain't working in -current (viz
<20071108140235.4653bf54@berkshire.machshav.com>).

On the 9th, gdt says that nmap is also doing things wrong. On the
10th, samba is also declared wrong. On the 11th, it is opined that
all extant in-tree programs should be fixed.
 
Now, personally, I don't care one way or the other about what the
"proper" or "sane" interface for SIOCGIFCONF is. (I would note that
the lignuces don't seem to return IPv6 addresses at all with
SIOCGIFCONF, thus providing an interesting slant on the sanity-or-not
of the ioctl; cf http://oss.sgi.com/archives/netdev/2000-02/msg00124.html )

However, I do care about random pieces of software breaking - and don't
really like the idea of NetBSD declaring that it has the One True Way
of invoking a given ioctl and that everybody else should adapt. I thus
don't think my original point is unreasonable: dhcpd, nmap, and samba -
hardly fringe pieces of software - failed to work properly after the
ioctl change, and repeated kludges have been committed to restore
functionality. 

So, I reiterate my original questions: isn't there far more software
using SIOCGIFCONF "incorrectly" than correctly? And if this is the
case, shouldn't racoon be fixed instead?