if you must have a `free_on_exit()` (for example, if you allocate a variable number of pointers in a loop) then build your own defer stack registering pointers using memory that you allocate

might as well free the NULL pointers as well - this is totally valid C and can simplify the code

I suppose the implication is that, checking for null allows your cleanup logic to be more complex than simply calling free()

for example, the object could be managing an open file, or an open socket

simply checking for NULL doesn't allow that - for example for something that might have been opened with fopen() needs to be closed with fclose() rather than free(), and you can't tell that from the pointer.

I think the implication was that they're pointers to objects that own resources (like containing FILE handles) and need to be "freed" with a custom function, not just "free".

    void my_thing_free(MyThing *thing) {
        fclose(thing->file);
        free(thing);
    }

assuming an associated "my_thing_new" that only returns a valid pointer when both the allocation and the fopen succeeded.