[Owasp-esapi-c++] Test Suite and Valgrind

Jeffrey Walton noloader at gmail.com
Fri Apr 9 16:05:24 EDT 2004

On Tue, Aug 23, 2011 at 1:20 AM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
> Jeff Walton wrote:
>> Kevin Wall wrote:
>>> If you really want to know how to handle the valgrind issues, I'd suggest a
>>> post to the Boost and valgrind forums.
>> http://lists.boost.org/boost-users/2011/08/70235.php
> Perhaps a better question is, if valgrind has this many complaints about the
> Boost libraries (or is this only about Boost::Test?), can we really
> trust it to NOT have memory leaks?
Its an open question. Does someone have another tool (perhaps purify)
that can be used to cross validate valgrind results?

> Because, if it does, maybe we should rethink about using it,
> or perhaps divert some effort into fixing the Boost libraries.
Hmmmm... Splitting sources is asking for trouble (ie, our 'fixed'
version versus boost's problematic sources). Plus, the fixes probably
won't find their way to my Ubuntu 10 or Fedora 14 systems through
Canonical or Red Hat. (Assuming there are some legitimate squawks).

Boost has a lot of Fan Boys. My feeling is they should fix their own
mess. I know I'm being a bit harsh, but I've been down this road with
other FOSS projects. I have found they want to write slick-ass, l33t,
K&R code like the kernel hackers*. You can't tell these folks to
validate all parameters before use, to use tools to locate mistakes
(ie, -Wall -Wextra and Valgrind), to use debug instrumentation to find
the point of first failure quickly, etc.

> If Boost has memory leaks that can be exploited, it can be
> used to attack apps that are using ESAPI for C++
> and there's very little we can do about that.
Yes. I kind of had tunnel vision - I was more concerned with our gear.
But you are right.


* Look at all the Comp Sci 101 mistakes from the l33t:
http://www.ubuntu.com/usn/usn-1189-1/. Its amazing they still don't
initialize their data structures properly and fully validate

More information about the Owasp-esapi-c++ mailing list