Comment by SpaceNoodled
Comment by SpaceNoodled 8 days ago
Not all C runtimes allow you to deallocate a null ppinter without consequence.
Comment by SpaceNoodled 8 days ago
Not all C runtimes allow you to deallocate a null ppinter without consequence.
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
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.
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?
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/msg001...
Despite the sparing number of cycles this saves per execution... I have to wonder how many cycles this has saved since.
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...