Hacker News Reader

Comment by tedunangst | Hacker News Reader

The free one at least will be detected immediately with a good libc, but nice idea. It gives me another idea though:

    #define free(x) do { free(x); x = NULL; } while (0)

Assuming you can turn it off just before shipping, this will hide many forms of double free during development which then show up when the evil line is deleted.

View on HN

That assumes 'x' is an lvalue, which it may very well not be (thus causing compilation errors, which would presumably get caught pretty quickly).

I'm having a very hard time thinking of an example where you'd free an rvalue. Function return, maybe, but without using the value? It (almost) had to be an lvalue in order to get the malloc into it. Ah, an unconst cast. free((void *)constx), but lots of compilers don't catch that. Is there something else you were thinking of?

There's also people doing stupid shit like free(&x), but those people don't need evil macros to dick up their code. :)

Function calls seem right - particularly if they're badly written. Also, this macro might give curious results when passed in ptr++ .

While this is C++, I've actually seen this particular construct: delete new SomeClass(...);

used as, basically, an eye-poppingly clever way of initializing something, doing work, and then cleaning up after.

    { SomeClass makeitso; }

Also, free(ptr++) is broken by design, the post increment value is useless. But free(*ptr++) is a good case.

> free(*ptr++)

Yes, of course - that's what I thought I'd written. Clearly not :)

I can think of one case in a project where we allocate a 4K block, fill the first n bytes with header info, and then add n bytes to the pointer and return it to something that's told it's getting a 4K - n byte block.

And then later it passes that return value to some function that deallocates the block, by calling free(((char *)p) - n).

Reply on news.ycombinator.com