4 ms·
I just had to google it: https://stackoverflow.com/questions/1912325/checking-for-null-before-calling-free https://stackoverflow.com/questions/1912325/checking-
by klingonopera 8y ago
I just had to google it:
https://stackoverflow.com/questions/1912325/checking-for-null-before-calling-free https://stackoverflow.com/questions/1912325/checking-for-nul...
There is history to this practice. And also, foresight:
1) I may want to redefine free().
2) If I do, my free() does not null-check.
3) Which is why my main code would null-check.
I'm an embedded developer, never do much on application work, and used to do that with C++, so I'm not too familiar with the heap allocation intricacies with C. But I'm quite sure that "delete" in C++ e.g. definitely needs to be null-checked (unless they changed that in some newer C++ revision, I always to try to code version-agnostic, and so far, have always managed).
In practice, I find it better to manually null-check pointers before deleting their contents, it either gets optimized away anyways or is an extra redundancy in code-or platform-migration.
- userbinator 8y agoI may want to redefine free(). 2) If I do, my free() does not null-check. I think redefining standard functions to do something very unexpected is very poor decision, especially when it means you now have to burden all its callsites with an extra check. But I'm quite sure that "delete" in C++ e.g. definitely needs to be null-checked (unless they changed that in some newer C++ revision No, it was never needed in C++ either (which given its desire to be backwards-compatible with C, is not surprising.) From the C++98 standard section 5.3.5, paragraph 2: "if the value of the operand of delete is the null pointer the operation has no effect."
- klingonopera 8y agoYes, you're right about delete. I still do it, and will still do it, though. I have my reasons. No, I wouldn't redefine free(), I'd use my own terminology, but I'd search the code for it and replace it verbatim, and seeing that it apparently is standard practice for both C++ and C to null-check their pointers before deletion, I have all the more reason to do so, because my code assumed that it didn't. Delete shouldn't null check, it should delete memory at location, no matter what address. It should be up to the implementation to check that pointer is valid. EDIT: I should maybe add that the next line of code is in my case almost always "pointer = NULL" following "free(pointer)". The null-check is not just a technicality of checking of pointer-validity ("Pointer not null?"), but also code-syntactics ("Has this item not been deleted yet?").
- shaklee3 8y agoWhat are your reasons?
- klingonopera 8y agoThey're in the edit. Precedence of code-flow indicators (I said "code-syntactics" in my original quote, that's wrong, sorry) are more important to me, than keeping away redundancies. What I am advocating for, is "Before you work on a pointer, check its validity", regardless of what follows after. It's just a general guideline, do it, even if you think it's senseless and redundant. Ever since I've adopted those basics, I've virtually reduced my problems with pointers to zero. There's danger in accidentally not null-checking, but none in accidentally double-checking. Therefore, the implementation should take care of this (too), or at least consider implications. I can't really take risks there. The original author of the article is asking me to "stop" this, which could put a lot of things at stake. No, thank you.
- jfk13 8y agoC++ explicitly allows `delete` to be called on a null pointer. E.g. see https://en.cppreference.com/w/cpp/language/delete https://en.cppreference.com/w/cpp/language/delete