On 28 November 2016 at 14:31, Antony Antony <[email protected]> wrote:
> isn't pfree smarter? linked with efence and leak-detective enabled.
> Which would be nice in test runs!
>
I'm more concerned with what we ship. I'd like it to fail faster.
/* stomp on memory! Is another byte value better? */
> memset(p, 0xEF, sizeof(union mhdr) + p->i.size);
>
>
Unfortunately that doesn't help with libraries like NSS where we have no
control over memory allocation (which is why the crypto code obsessively
tries to kill NSS related pointers).
I'm also skeptical that 0xFE is a good value. There's no real guarantee
that the address is invalid, and the result looks more like a random memory
smash (and not use after free). On the other hand debugging an NPE is
obvious and straight forward, and we know 0==NULL (see earlier thread),
that embedded compilers can add NULL checks.
> There was another reason someone, I think Hugh, bring up.
> something like - libreswan code deal with pointers to pointers so assigning
> NULL is not useful.
>
>
Not useful or harmless? For instance:
{
u_int8_t *bytes = alloc_things(u_int8_t, 10, "bytes");
...
pfree(bytes); bytes = NULL;
}
will get tossed by the compiler.
> may be there is a better reason to assign NULL now!
>
>
> On Mon, Nov 28, 2016 at 12:07:05PM -0500, Andrew Cagney wrote:
> > I'd like the change:
> > pfree(P)
> > pfreeany(P)
> > so that "P" is set to NULL after the free.
> >
> > While a tacky hack, it might help flush out some reference after
> > free's I suspect we've got lurking.
> >
> > Andrew
> > _______________________________________________
> > Swan-dev mailing list
> > [email protected]
> > https://lists.libreswan.org/mailman/listinfo/swan-dev
>
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
