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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
