Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some bits on malloc(0) in C being allowed to return NULL

utcc.utoronto.ca

Post reply on HN
Print view View original

41–50 of 84 posts

Re: Some bits on malloc(0) in C being allowed to return NULL

#41

Post by hansvm »

Lvl999Noob wrote: post #36

Can someone tell me a usecase where you want multiple allocations of size 0, each one with a unique address, and each one unique from any other allocation (hence necessarily removing that pointer from being allocated to anything else) but can't use malloc(1) instead? I think it would be much better if malloc(0) just returned 1 or -1 or something constant. If the programmer needs the allocation to have a unique addres…

It's occasionally useful to want multiple allocations of size 0, each one with a valid address -- generic containers parsing something as a some sort of sequence object and you want all code interacting with it to do something valid. I'd be hard-pressed to see where you'd need those to be unique though. Basically any integer should be fine.

Re: Some bits on malloc(0) in C being allowed to return NULL

#42

Post by bobmcnamara »

masfuerte wrote: post #34
MaxBarraclough wrote: post #31

Earlier quoted context omitted.

Not just POSIX, also the ISO C standard itself. https://en.cppreference.com/w/c/memory/malloc

That doesn't say the pointer has to be unique.

It is in ANSI 89, under memory management functions.

Re: Some bits on malloc(0) in C being allowed to return NULL

#44

Post by JdeBP »

Joker_vD wrote: post #35
DSMan195276 wrote: post #22

Earlier quoted context omitted.

> allocating a few bytes that weren't asked for. FWIW the alignment guarantees of `malloc()` mean it often will have to allocate more than you ask for (before C23 anyway). You can't 'legally' use this space, but `malloc()` also can't repurpose it for other allocations because it's not suitably aligned. That said I still agree it's a hack compared to just using `malloc(1)` for this purpose, it's well-defined and funct…

> before C23 anyway Did they change "suitably aligned for any object type" to "suitably aligned for any object type with size less than or equal to what was requested" or something like in C23?

See https://news.ycombinator.com/item?id=44390258 .

Re: Some bits on malloc(0) in C being allowed to return NULL

#45

Post by sgerenser »

Someone wrote: post #26
bobmcnamara wrote: post #9

Earlier quoted context omitted.

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.

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

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.

Re: Some bits on malloc(0) in C being allowed to return NULL

#46

Post by xenadu02 »

Lvl999Noob wrote: post #36

Can someone tell me a usecase where you want multiple allocations of size 0, each one with a unique address, and each one unique from any other allocation (hence necessarily removing that pointer from being allocated to anything else) but can't use malloc(1) instead? I think it would be much better if malloc(0) just returned 1 or -1 or something constant. If the programmer needs the allocation to have a unique addres…

Because zero-size types exist which you might want to take the address of. Possibly as a result of macro substitution or templating mechanism that only appears in certain build configurations.

It means you don't need a bunch of special-case handling if one out of 27 types ends up with zero size in some situation. It just all works the same way. Especially the unique address part because that would be an annoying source of difficult to track bugs.

Re: Some bits on malloc(0) in C being allowed to return NULL

#47

Post by bobmcnamara »

jcranmer wrote: post #40
masfuerte wrote: post #34

Earlier quoted context omitted.

That doesn't say the pointer has to be unique.

cppreference isn't the standard, and while the text they write looks like it's the same verbiage that would be authoritative, it's not. (And there's some criticism of it from standards committee members in that regard). The current C standard text says: > The order and contiguity of storage allocated by successive calls to the aligned_alloc, calloc, malloc, and realloc functions is unspecified. The pointer returned i…

> Each such allocation shall yield a pointer to an object disjoint from any other object.

Phrasing could be slightly more clear to prevent someone from making the argument that -1 is disjoint from all objects as it does not point to an object

Re: Some bits on malloc(0) in C being allowed to return NULL

#48

Post by bobmcnamara »

comex wrote: post #28
f1shy wrote: post #27

Earlier quoted context omitted.

Isn’t -1 basically 0xffff which is a constant pointer? What am I missinterpreting?

If you call malloc(0) multiple times (without freeing in between) and get -1 each time, then the pointer is not unique.

But do we need a unique pointer or merely a pointer that is disjoint from all objects?

Re: Some bits on malloc(0) in C being allowed to return NULL

#49

Post by bobmcnamara »

Someone wrote: post #26
bobmcnamara wrote: post #9

Earlier quoted context omitted.

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.

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

Those are identifiable by the end state of the heap not being empty.

Re: Some bits on malloc(0) in C being allowed to return NULL

#50

Post by bobmcnamara »

sgerenser wrote: post #45
Someone wrote: post #26

Earlier quoted context omitted.

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

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.

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.
Post reply on HN