3 ms·

I might be missing something, but how does this help in checking for leaks? I mean, I guess you could use it to check for leaks specifically of 0-sized allocati

I might be missing something, but how does this help in checking for leaks? I mean, I guess you could use it to check for leaks specifically of 0-sized allocations, but wouldn’t it be better just to return NULL and guarantee that 0-sized allocations never use any memory at all?

bobmcnamara 1y ago
At the end of main, if the count wasn't balanced, then you knew you had a mismatch between malloc()/free(). If malloc() had returned a real pointer, you'd have to free that too. > wouldn’t it be better just to return NULL and guarantee that 0-sized allocations never use any memory at all? Better: takes less memory Worse: blinds you to this portability issue.
- Someone 1y ago
  > At the end of main, if the count wasn't balanced, then you knew you had a mismatch between malloc()/free(). A mismatch between malloc(0) and free(-1). You’d know nothing about calls to malloc with non-zero sizes.
  - sgerenser 1y ago
    Yeah, exactly, that’s my point. How many programs have memory leaks limited to (or even just materially affected by) 0-sized allocations? I’d have to imagine its a very small minority.
    - bobmcnamara 1y ago
      They're uncommon for sure. In the past they've been an issue for me on constrained systems where they can frag the heap as badly as any other long lived allocation.
  - bobmcnamara 1y ago
    Those are identifiable by the end state of the heap not being empty.
spacechild1 1y ago
> but wouldn’t it be better just to return NULL and guarantee that 0-sized allocations never use any memory at all? This works if you are only interested in the overall memory balance. However, if you want to make sure that all malloc() calls are matched by a free() call, you need to distinguish between NULL and a successfull zero-sized allocation, otherwise you run into troubles when you call free on an "actual" NULL pointer (which the standard defines as a no-op).

bobmcnamara 1y ago

At the end of main, if the count wasn't balanced, then you knew you had a mismatch between malloc()/free(). If malloc() had returned a real pointer, you'd have to free that too. > wouldn’t it be better just to return NULL and guarantee that 0-sized allocations never use any memory at all? Better: takes less memory Worse: blinds you to this portability issue.

Someone 1y ago
> At the end of main, if the count wasn't balanced, then you knew you had a mismatch between malloc()/free(). A mismatch between malloc(0) and free(-1). You’d know nothing about calls to malloc with non-zero sizes.
- sgerenser 1y ago
  Yeah, exactly, that’s my point. How many programs have memory leaks limited to (or even just materially affected by) 0-sized allocations? I’d have to imagine its a very small minority.
  - bobmcnamara 1y ago
    They're uncommon for sure. In the past they've been an issue for me on constrained systems where they can frag the heap as badly as any other long lived allocation.
- bobmcnamara 1y ago
  Those are identifiable by the end state of the heap not being empty.

spacechild1 1y ago

> but wouldn’t it be better just to return NULL and guarantee that 0-sized allocations never use any memory at all? This works if you are only interested in the overall memory balance. However, if you want to make sure that all malloc() calls are matched by a free() call, you need to distinguish between NULL and a successfull zero-sized allocation, otherwise you run into troubles when you call free on an "actual" NULL pointer (which the standard defines as a no-op).