Subject: None
To: None <perry@piermont.com>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: current-users
Date: 03/26/1996 17:25:23
>>Ty Sarna writes:
>> Still though, void main in "hosted" (~= userland) programs is SO common
>> that the standard might as well be changed to allow it.

>Many bad practices are common. A compiler warning or two and thirty
>seconds hacking one time too many will retrain people. I was a bit
>unclear on this point once, but a vicious compiler taught me the right
>thing.

I happen to think there's bad practice and then there's "bad practice".

Two of the main()s that were changed recently was named/ns_main.c
and named-xfer/named-xfer.c.   Those programs were (I assume,
deliberately) written to avoid returning from main(). They consistently
use exit() instead.  The end of main() is marked with /*NOTREACHED*/
for lint.   I think there are perfectly reasonable arguments for
declaring main() as returning void in such circumstances.  It tells
both the compiler, and future maintainers,  what that _particular_
main() is intended to  do.


There's one very important principle at stake here that I haven't
seen explicitly addressed.  That principle is that ``third-party''
software in the NetBSD tree should be kept as close as possible
to the third party's original version -- at least, if the third
party is actually maintaining that software.   Doing anything else
diverts a valuable and limited resource to maintaining what, for
want of a  better term and without meaning to sound perjorative,
I would call "local hacks".

IMHO, adding local hacks to named is not necessarily "added value"
or even sensible.   Has anyone contacted the bind mailing list
and _asked_ if there's a good reason for declaring main() as void
in the named source?  Maybe BIND needs to run on systems where
returning a value from main() doesn't work?  Or, has anyone asked
 if Vix is willing to buy back the recent NetBSD changes?

I, personally, happen to have more faith in Paul Vixie and the team
that works on BIND and named -- specifically, in their ability to
produce reliable, well-tested, portable, well-thought-out software,
than in someone who advocates following standards, simply (as far as I
can see) for the sake of following standards.