You're right that it's not needed in my example but sometimes the thing that you're freeing has pointers inside it which themselves have to be freed first and in that case you need the if.

There are several other issues I haven't shown like what happens if you need to free something only when the return code is "FALSE" indicating that something failed.

This is not as nice as defer but up till now it was a comparatively nice way to deal with those functions which were really large and complicated and had many exit points.

If you have something which contains pointers, you should have a destructor function for it, which itself should check if the pointer is not NULL before attempting to free any fields.

We are talking about C. A destructor function in C is a function that gets called when the library gets unloaded. No you shouldn't have a destructor function for it.

The C language has no such concept of attribute destructor and I am not talking about attribute destructor.

I just mean, in the simple English sense, a function which exists to deallocate a structure.

That's certainly one way to do it if you're writing all the code.

If you have something which doesn't come with such a function, nothing stops you writing it?

But it does keep one in the habit of using NULL checks.

It is pointless, because in Linux all you get is a virtual address. Physical backing is only allocated on first use.

In other words, the first time you access a "freshly allocated" non-null pointer you may get a page fault due to insufficient physical memory.

By default, yes. You can configure it to not overcommit

Right, but as a programmer you rarely have control over that. And even if you do, you often can't handle out of memory errors gracefully.

Thus, for a typical situation it is reasonable to log the error and bail out, rather than adding extra custom error handling around every single memory allocation, which ends up being code that is never tested.