5 ms·

> 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 doi

> 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.

SpaceNoodled 2y ago
Not all C runtimes allow you to deallocate a null ppinter without consequence.
- lifthrasiir 2y 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#page=270 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf#p...
  - dathinab 2y 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 2y 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.
- deleted 2y ago
  [deleted]
- magicalhippo 2y 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 http://jfxpt.com/library/c89-draft.html#4.10.3.2 [2]: https://en.cppreference.com/w/c/memory/free https://en.cppreference.com/w/c/memory/free
  - tjalfi 2y ago
    I wish I didn't know this, but it could be SunOS4[0] which went out of support in 2003. It's probably the most well-known OS where free(NULL) wasn't supported. I would like to think that people aren't writing new code for it. [0] https://lists.gnu.org/archive/html/bug-gnulib/2020-12/msg00164.html https://lists.gnu.org/archive/html/bug-gnulib/2020-12/msg001...
- jcelerier 2y ago
  If free(NULL) doesn't work it's not the C programming language but something else
- jabl 2y 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 2y ago
    Despite the sparing number of cycles this saves per execution... I have to wonder how many cycles this has saved since.
- epcoa 2y ago
  Life is too short to deal with such brokenness then. Seriously, those jobs typically don't pay more than peanuts anyhow.
Traubenfuchs 2y ago
If it's really fine, shouldn't the compiler optimize that if away?
- lifthrasiir 2y ago
  Of course (there are several GCC attributes for that), but it is not really like that an additional check improves readability anyway.
- cozzyd 2y ago
  It has different performance characteristics
  - kadoban 2y ago
    Isn't that common with changes the optimizer does? What else is the point of it?
dathinab 2y 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.
deleted 2y ago
[deleted]
cross 2y 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.

SpaceNoodled 2y ago

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

lifthrasiir 2y 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#page=270 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf#p...
- dathinab 2y 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 2y 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.
deleted 2y ago
[deleted]
magicalhippo 2y 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 http://jfxpt.com/library/c89-draft.html#4.10.3.2 [2]: https://en.cppreference.com/w/c/memory/free https://en.cppreference.com/w/c/memory/free
- tjalfi 2y ago
  I wish I didn't know this, but it could be SunOS4[0] which went out of support in 2003. It's probably the most well-known OS where free(NULL) wasn't supported. I would like to think that people aren't writing new code for it. [0] https://lists.gnu.org/archive/html/bug-gnulib/2020-12/msg00164.html https://lists.gnu.org/archive/html/bug-gnulib/2020-12/msg001...
jcelerier 2y ago
If free(NULL) doesn't work it's not the C programming language but something else
jabl 2y 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 2y ago
  Despite the sparing number of cycles this saves per execution... I have to wonder how many cycles this has saved since.
epcoa 2y ago
Life is too short to deal with such brokenness then. Seriously, those jobs typically don't pay more than peanuts anyhow.

Traubenfuchs 2y ago

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

lifthrasiir 2y ago
Of course (there are several GCC attributes for that), but it is not really like that an additional check improves readability anyway.
cozzyd 2y ago
It has different performance characteristics
- kadoban 2y ago
  Isn't that common with changes the optimizer does? What else is the point of it?

dathinab 2y 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.

deleted 2y ago

[deleted]

cross 2y 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.