svn commit: r245494 - head/bin/pwait

[John Baldwin]

On Wednesday, January 16, 2013 4:36:30 pm Xin Li wrote:
> On 01/16/13 08:11, John Baldwin wrote:
> > On Wednesday, January 16, 2013 1:49:40 am Xin LI wrote:
> >> This doesn't seem right -- you should never release memory before
> >> exit, especially for memory allocated in main(), unless this
> >> "main" is intended for different purpose like a monolithic shell
> >> that wants to avoid exec(). Note that pwait(1) have multiple exit
> >> points I don't think it's practical.
> >>
> >> Would you mind if I commit this changeset instead?  I have the
> >> return -> exit change in my queue long ago but only noticed it
> >> today...
> >
> > I think the free shouldn't be there as well, but I think requiring
> > an exit() instead of return to "fix" it is bogus as well.  The
> > static analyzer is just broken in this case.  main() is special and
> > returns from it should be treated like exit() and not cause false
> > warnings about memory leaks.
> 
> Well, being a horrible idea itself to redefine main() to something
> else and expect the module to do no harm to its caller, I think Eitan
> still have a valid point that it could be a bad idea to ban this in
> wholesale within compiler, as the C standard don't ban using return's
> in main().

As I said in a later followup, I think there should be an option, but it
should default to treating return from main as exit().

> In style(9) the examples do use exit() for main() by the way.

Yes, but as other folks have pointed out, return() can be more suitable
in other cases (specifically with C++ when you want objects in scope to
be properly destroyed).

-- 
John Baldwin