Comment by jclulow

Comment by jclulow 8 days ago

18 replies

> Let's ignore for now that this will surprise every C developer out there that have been doing if (NULL != ptr) free(ptr) for 50 years now.

If you've been doing C for five decades, it's a shame not to have noticed that it's totally fine to pass a NULL pointer to free().

FWIW, I don't otherwise agreed with the thesis. I've written probably ten FFI wrappers around C libraries now, and in every case I was able to store C pointers in some Rust struct or other, where I could free them in a Drop implementation.

I also think it's not actually that unusual for C allocators (other than the truly ancient malloc(3C) family) to require you to pass the allocation size back to the free routine. Often this size is static, so you just use sizeof on the thing you're freeing, but when it's not, you keep track of it yourself. This avoids the need for the allocator to do something like intersperse capacity hints before the pointers it returns.

cross 6 days ago

> If you've been doing C for five decades, it's a shame not to have noticed that it's totally fine to pass a NULL pointer to free().

Or that calling one's FFI function inside of an `assert` means it will be compiled out if the `NDEBUG` macro is defined.

Traubenfuchs 8 days ago

If it's really fine, shouldn't the compiler optimize that if away?

  • lifthrasiir 8 days ago

    Of course (there are several GCC attributes for that), but it is not really like that an additional check improves readability anyway.

  • cozzyd 7 days ago

    It has different performance characteristics

    • kadoban 6 days ago

      Isn't that common with changes the optimizer does? What else is the point of it?

[removed] 8 days ago
[deleted]
dathinab 8 days ago

> Let's ignore for now that this will surprise every C developer out there that have been doing if (NULL != ptr) free(ptr) for 50 years now.

if you did 50 years of development and haven't realized that in projects crossing language (or just separately complied C libs) you have to free things where you create them and can't use the many many libraries which do require you to use their own free/destruction functions and don't even have understand that free is flat and in turn you need to also "destruct" each item in a struct manually and that if you don't have a custom function for this it can easily become a huge bug prone mess

.. then I'm really not sure how this happened tbh.

but if you are not a senior C/C++/FFI developer maybe not a C/C++/FFI developer at all it's not hard to see how you might have missed this things tbh.

SpaceNoodled 8 days ago

Not all C runtimes allow you to deallocate a null ppinter without consequence.

  • lifthrasiir 8 days ago

    Such C runtime is not standard-compliant [1]:

    > The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs.

    [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf#p...

    • dathinab 8 days ago

      doesn't matter

      50 years ago non standard compliance was the norm, even today it is quite common (to use non compliant extensions)

      and there is also stuff like caches, arena allocations, jemalloc etc. which might not be linked against libc/free and might require manual free function usage, external APIs providing a their own free/destruction functions is really really normal

      • lifthrasiir 8 days ago

        Accepting a null pointer in free is a very easy part of the conformance and I am yet to see a libc implementation that doesn't so far, so your statement should be pretty much outdated even if it were true. And since malloc-free interface is so popular in C, other allocators are also commonly modelled after that (plus their own APIs) anyway; jemalloc for example has an usual free with the standard interface.

  • magicalhippo 8 days ago

    Even the C89 draft[1] says passing null should do nothing, and as far as I can tell it's still[2] the case.

    Which runtimes would this be?

    [1]: http://jfxpt.com/library/c89-draft.html#4.10.3.2

    [2]: https://en.cppreference.com/w/c/memory/free

  • jabl 8 days ago

    That was a long time ago. A decade or so ago Jim Meyering did experiments with a lot of allocators, and subsequently went on a spree removing NULL checks before free() in a lot free software toolchain projects (gcc, gdb, binutils, etc).

    • 1propionyl 6 days ago

      Despite the sparing number of cycles this saves per execution... I have to wonder how many cycles this has saved since.

  • jcelerier 8 days ago

    If free(NULL) doesn't work it's not the C programming language but something else

  • epcoa 8 days ago

    Life is too short to deal with such brokenness then.

    Seriously, those jobs typically don't pay more than peanuts anyhow.

  • [removed] 8 days ago
    [deleted]