svn commit: r287236 - head/bin/df

[Conrad Meyer]

On Fri, Aug 28, 2015 at 1:36 AM, Xin Li <delphij at delphij.net> wrote:
>
>
> On 8/27/15 21:43, Alexey Dokuchaev wrote:
>> On Fri, Aug 28, 2015 at 12:44:59AM +0000, Xin LI wrote:
>>> New Revision: 287236
>>> URL: https://svnweb.freebsd.org/changeset/base/287236
>>>
>>> Log:
>>>   Use exit() instead of return in main().
>>
>> Because?..
>
> Because the explicit exit() have a subtle difference from returning from
> main(), and that could confuse static analyzers.  I thought it was
> obvious and too much for trivial changes like this.  Let me try again:
>
> C standard defines that when main() returns to the startup code, the
> latter is required by the standard to call exit() with main()'s return
> value, should main() be defined to return a type compatible with int.
> On FreeBSD, this is done by lib/csu/${ARCH}/crt1.c.
>
> Note, however, that return'ing from a C function means the stack
> contents, for example, variables defined in function scope, are
> discarded.  Therefore, if, let's say one defined a pointer in the
> function scope, like:
>
>         void *p;
>
> And then later assign a block of memory allocated from heap to it:
>
>         p = malloc(size);
>
> Since p is in function scope, upon return, it's gone.  If there is no
> other pointers that referenced the memory block referenced by p, the
> memory block is _technically_ leaked.
>
> This does not matter in practice because exit() or returning from main
> are both the points of termination, and the kernel would then reclaim
> all memory pages that belongs to the process.  However, doing exit()
> makes it more explicit that this is the point of no returns, actually,
> it hints the compiler or a static analyzer to do the right thing without
> needing to make main() a special case.


So, a better commit log may have been:

"Use exit() instead of return in main() to work around a broken static analyzer"

Any C static analyzer must understand main().

Best,
Conrad