<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 9 September 2014 07:49, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 08 Sep 2014 11:00:37 -0700<br>
Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
> On 09/07/2014 11:28 PM, Pekka Paalanen wrote:<br></span><span class="">> Trying to shut up valgrind on exit is an exercise in futility and adding<br>
> a free() to try to shut it up often requires lots of unwanted code<br>
> changes as this demonstrates.<br>
<br>
</span>Yes, there are at least two schools on that. Some say, that a one-time<br>
allocation cannot be a leak. That is true, but only as long as it stays<br>
a one-time allocation. Guaranteeing that is the hard part.<br>
<br>
I prefer plugging all reports that can be plugged without corner-case<br>
bugs, so that actual leaks do not get hidden between these. It is very<br>
frustrating to analyze Valgrind reports just to create a suppressions<br>
file so that I might see only the real leaks.<br></blockquote><div><br></div><div>Yes, this. If Valgrind isn't instantly and immediately usable, no-one will use it: much like there are no gcc warnings which are 'fine' to have, since they just hide all the real ones.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I also favour consistency in coding style. We code all "normal"<br>
functions to not leak, so why not main(), too.<br></blockquote><div><br></div><div>And if/when libweston becomes a thing, there will be no 'normal' functions.</div><div><br></div><div>Cheers,</div><div>Daniel </div></div></div></div>