sin_zero, redux

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

Back about two weeks ago I wrote about sin_zero and its relevance to
the radix tree used by AF_INET's routing table.

Sunday, I finally got together the round tuits to try eliminating
sin_zero altogether, this reinforced by remarks during the previous
thread that not everyone has sin_zero and thus code with suitable
portability aspirations won't, or at least shouldn't, use it
explicitly.

Of course, I don't know whether anyone will care.  Consider this a
report back to the community on an experiment, if you will. :)

Working with 4.0.1, because that's what I have easy to build at the
moment, I removed sin_zero from the struct definition in
sys/netinet/in.h.  Then it took fixing only two other files to get the
kernel to build, sys/nfs/nfs_export.c and sys/netinet/raw_ip.c.  Then I
did a sweep for files which textually contained "sin_zero" and fixed
them; this meant gnu/dist/gdb/sim/arm/main.c,
gnu/dist/gdb6/sim/arm/main.c, share/man/man4/inet.4,
usr.bin/talk/ctl.c, and usr.sbin/nfsd/nfsd.c, and ignoring a few other
occurrences (eg, in RFCs quoted in files under dist/).  All of these
fixes were fairly obvious upon looking at the references.

Then upon attempting a build of the world, I found I had to fix
sbin/routed/output.c and sbin/routed/table.c, which contained
initializers which assume the presence of a compound field after
sin_addr.

Then the world built.

AF_INET doesn't work, and I think I know why.  This also explains why
it didn't work when I just reconfigured the routing table in
inetdomain.  ARP processing uses sockaddr_inarp (<netinet/if_inarp.h>)
for its routes.  This struct is just like standard sockaddr_in except
that, in place of sin_zero, it has a second struct in_addr and two
16-bit values, and it actually cares what's there, so for inetdomain's
routing table to ignore that data breaks it.  Unwarranted chumminess
with the implementation at its finest; at the very least this deserves
big comments on inetdomain where its routing table is configured, and
on struct sockaddr_in explaining why sin_zero has to be there.  AF_INET
networking seems to work on-subnet anyway, and I'm not sure why, since
that uses ARPs too - perhaps it was total coincidence....

I am relieved to finally (think I) understand why sin_zero is as
necessary as it appears to be.  I still think requiring sin_zero to be
zero for most interfaces (bind(), routing socket messages, etc) to work
is a bug, or at best a misfeature; I think it should be zeroed upon
reception by the kernel from userland rather than letting userland
leave trash there.  But I feel much better understanding why things
broke so mysteriously when I shrank the routing table.

I'm now going back to a source tree with sin_zero and will be adding
prominent comments to it explaining why sin_zero is necessary.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B