Zero is a number just like any other number
Zero is a number just like any other number
Posted Oct 25, 2024 10:05 UTC (Fri) by mb (subscriber, #50428)In reply to: Zero is a number just like any other number by Wol
Parent article: realloc() and the oversize importance of zero-size objects
And the pattern ptr = realloc(ptr, ...) is dangerous (memory leaks), if your size can be non-zero. This pattern should not be encouraged.
The real solution is to avoid using C altogether and switch to a sane language with a sane allocator.
Posted Oct 25, 2024 11:12 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (4 responses)
How do you chop an atomic statement in half?
> And the pattern ptr = realloc(ptr, ...) is dangerous (memory leaks), if your size can be non-zero. This pattern should not be encouraged.
You should not encourage the CORRECT use of realloc? You should know whether you want to re-use ptr or not, and you should know what sort of object you're going to put there - if the answer is "nothing" then allocate zero space. You're advocating careless programming ... you'll say I'm exaggerating, but taking your argument to its extreme it sounds like "don't bother freeing ptr, you don't know if you're going to re-use it", which is probably worse on the memory leak front ...
> The real solution is to avoid using C altogether and switch to a sane language with a sane allocator.
Agreed :-)
Posted Oct 25, 2024 12:00 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Easy: That approach was even tried in Go (where proper way to append something to the slice is It would have been “correct” if it was taught that way from the beginning (preferably in first edition of K&R). But, alas, in our world that haven't happened, thus it falls fully into “very non-standard and unusual non-portable code that some weirdos try to promote for no good reason”. Typical C programmer, in today's world, wouldn't even know that And you shouldn't do any other mistakes too. Which means that such code is useless for real programmers who are not taught to use it and it's also useless for imaginary “perfect” programmers who never do mistakes. Who could benefit from it, then? Nope. He (and me, too) advocate familiar programming that's based on the tools that we have today. You are imagining some alternate world, where C is different, C programmers are different and Sorry, but it's really too late to push for some new C and new set of C programmers and new C standard library that could, collectively, embrace that “brave new way” of dealing with memory allocations.
Posted Oct 25, 2024 12:40 UTC (Fri)
by mb (subscriber, #50428)
[Link] (2 responses)
It's not atomic.
> You should not encourage the CORRECT use of realloc?
No. It's usually incorrect to overwrite the pointer with the return value of realloc before checking for NULL return. If realloc fails to allocate, it does not free the pointer and returns NULL. If you overwrite your only pointer with the NULL return, you have leaked the original allocation.
Posted Oct 25, 2024 18:27 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Sure, but if you want not to allocate memory, but to free it and that fails… what are the mitigations? At this point I would assume that allocator would just stop the program because it's probably the best response that it could do. And in some alternate reality where this behavior is mandated… and I would argue that even in that world it would have been bad design, but familiarity of the pattern would have made it justifiable. But inventing and pushing new convention like that in our world? That's just… I don't even know strong enough words to describe what I think about that idea.
Posted Oct 25, 2024 18:30 UTC (Fri)
by mb (subscriber, #50428)
[Link]
I commented on something else.
I was just saying that ptr = realloc(ptr, ...) was a bad pattern, because it's wrong for all cases *except* the free/zero case (maybe; implementation defined; if not UB).
Posted Oct 31, 2024 5:33 UTC (Thu)
by milesrout (subscriber, #126894)
[Link]
this has nothing to do with the fact p = realloc(p,...) is erroneous. Of course it is wrong! It is obviously nonsensical rubbish code with any allocator. If you cant get this basic stuff right then i dont think a "sane" allocator would save you from writing hundreds of other serious bugs in your program
Zero is a number just like any other number
> How do you chop an atomic statement in half?
Zero is a number just like any other number
p = realloc(q, 0);. Bam: your pointer is no longer clobbered and can be happily reused.s = append(s, t); and not just simply append(s, t); or s.append(t);) and causes nothing but grief.ptr = realloc(ptr, 0); is supposed to free memory and would look, in vain, for free, which would lead not to greater safety, but to greater confusion.realloc is different, too!Zero is a number just like any other number
> If you overwrite your only pointer with the NULL return, you have leaked the original allocation.
Zero is a number just like any other number
realloc was required to behave like that… and all C courses would have teached you to use that ability… yes, in such a world, use of realloc would have been justified.Zero is a number just like any other number
Zero is a number just like any other number