Hacker News Reader

Comment by mac3n | Hacker News Reader

this is way overkill

the way i do this in C looks like

    initialize all resource pointers to NULL;

    attempt all allocations;

    if all pointers are non-NULL, do the thing (typically calling another routine)

    free all non-NULL pointers

realloc(ptr, 0) nicely handles allocations and possible-NULL deallocations

View on HN

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.

Reply on news.ycombinator.com