From: Arkadiusz Drabczyk <arkadiusz-42WfZ8EewN5g9hUCZPvPmw@public.gmane.org>
To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: valgrind tests don't test anything
Date: Mon, 9 Mar 2020 17:31:00 +0100 [thread overview]
Message-ID: <20200309163100.GA15388@comp.lan> (raw)
In-Reply-To: <20200309082920.GF617846-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
On Mon, Mar 09, 2020 at 07:29:20PM +1100, David Gibson wrote:
> Uhh... I don't think it's accurate to say the valgrind tests don't
> test *anything*. They're not checking for leaks, but they're still
> checking for use after free, use of uninitialized data and so forth.
Ok, indeed, sorry, my fault. I should have said that valgrind tests
do not check for memory leaks.
> I'm actually not particularly concerned about leaks in dtc, because
> it's a strictly short runtime transient process. You can think if it
> as using the OS process as a rudimentary pool allocator. Leaks in
> libfdt would be a problem... but libfdt doesn't use the allocator at
> all, so they're essentially impossible. Between those two is probably
> why I never enabled the valgrind leak detector.
Ok, I see. As a sidenote, --tool=memcheck is the default option for
valgrind so it could be removed but it's not a big deal.
--
Arkadiusz Drabczyk <arkadiusz-42WfZ8EewN5g9hUCZPvPmw@public.gmane.org>
prev parent reply other threads:[~2020-03-09 16:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-08 18:32 valgrind tests don't test anything Arkadiusz Drabczyk
[not found] ` <20200308183221.GA10025-Zrdc6muVEXg@public.gmane.org>
2020-03-09 8:29 ` David Gibson
[not found] ` <20200309082920.GF617846-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
2020-03-09 16:31 ` Arkadiusz Drabczyk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200309163100.GA15388@comp.lan \
--to=arkadiusz-42wfz8eewn5g9huczpvpmw@public.gmane.org \
--cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
--cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.