On 17 January 2013 10:35, John Baldwin wrote:
> No, it is clearly a bug. It is a waste of time and adds obfuscation (and
> runtime overhead) to go free a bunch of stuff just before a return() from
> main().
It is by-design according to the clang folks. They have expressed in
interest in offerin
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
> >>
On Wednesday, January 16, 2013 2:15:00 pm Eitan Adler wrote:
> On 16 January 2013 13:11, Xin Li wrote:
>
> > Yes I did. Using exit(3) tells clang that this is the final exit and
> > thus eliminates the warning.
> >
> > It sounds like a bug (or arguably a feature) that clang does not
> > recogniz
On Wed, 16 Jan 2013, Eitan Adler wrote:
On 16 January 2013 13:11, Xin Li wrote:
Yes I did. Using exit(3) tells clang that this is the final exit and
thus eliminates the warning.
It sounds like a bug (or arguably a feature) that clang does not
recognize return in main()s...
It is not a bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
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 intende
On Wed, Jan 16, 2013 at 10:41 AM, Xin Li wrote:
...
> Well, calling exit(3) actually do less on C++ (dtor's are not called
> in this case, if any local object is declared on stack, which is done
> when the code say 'return') but the difference is less on C.
Good to know -- thanks!
> In style(9
On 16 January 2013 13:11, Xin Li wrote:
> Yes I did. Using exit(3) tells clang that this is the final exit and
> thus eliminates the warning.
>
> It sounds like a bug (or arguably a feature) that clang does not
> recognize return in main()s...
It is not a bug: see
http://clang-developers.42468.
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 pwai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/16/13 10:17, Garrett Cooper wrote:
> On Jan 16, 2013, at 10:11 AM, Xin Li wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>>
>> On 01/16/13 09:47, Eitan Adler wrote:
>>> On 16 January 2013 01:49, Xin LI wrote:
This doesn't
On Jan 16, 2013, at 10:11 AM, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 01/16/13 09:47, Eitan Adler wrote:
>> On 16 January 2013 01:49, Xin LI wrote:
>>> This doesn't seem right -- you should never release memory before
>>> exit, especially for memory allocated in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/16/13 09:47, Eitan Adler wrote:
> On 16 January 2013 01:49, 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
On 16 January 2013 01:49, 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 multip
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.
Wo
Author: eadler
Date: Wed Jan 16 05:03:52 2013
New Revision: 245494
URL: http://svnweb.freebsd.org/changeset/base/245494
Log:
Free memory before exiting in order to silence a warning from the clang
static analyzer
Approved by: cperciva
MFC after:3 days
Modified:
head/bin/pwait/pw
14 matches
Mail list logo