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

But it's incorrect.  Writing "i = i++" to tell a future maintainer
that your goal is to set i to the new value is wrong too.

There are perfectly reasonable arguments; none of them make it legal
C.

>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?

There are *NO* systems where you cannot return int from main.  (Except
possibly plan 9, which compiles a language largely different from C in
mayn ways.)  It is *GUARANTEED* by ANSI that you can return a value from
main, and that doing so is equivalent to passing that value to exit,
except for the handling of local buffers in main that have been passed
to setvbuf.  There has *NEVER* been a hosted environment that did not
let you declare main to return int, and 95% of them use that return
value.

This is like asking if there's a good reason to write
	printf("%Lf")
in case there's a good reason to use it on machines that won't properly
print a long double value.

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

Without standards, we can't run anyone's software.  I have a lot of
faith in Richard Stallman.  He's probably better at programming than
I'll be any time in the next decade or so.

He recently advocated writing

	error(s, i1, i2, i3)
		char *s;
		int i1, i2, i3;
	{
		fprintf(stderr, "error: ");
		fprintf(stderr, s, i1, i2, i3);
	}

and has put this in the GNU coding standards.

He's wrong.  It's broken, it's stupid, and it does not perform even close
to correctly on a non-trivial set of systems (and works on even fewer
if you try to prototype it.)

Experienced programmers can and will make mistakes.  Correcting them is
a win.

If I had proposed forcing all programs to return a specific value as a
"fix", or if I had advocated removing all calls of exit(), and rewriting
program logic to turn them into returns that led to returns to main, I
would probably see your concerns.  As is, this is merely rooting out a
common mistake, and there's no reason at all to leave things alone.

And I haven't contacted Vixie, but only because I lack his email address.
I did tell the maintainers of GNU tar, sort, and cpio, and they are all
fixing it for the next releases.

-s