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

11–20 of 84 posts

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

#11

Post by cjensen »

AaronDinesh wrote: post #5

Why should it be allowed to return a valid pointers anyways? Surely it should always return NULL?

There are three reasonable choices: (a) return the null pointer (b) return a valid unique pointer and (c) abort().

The point of the original C Standard was to make rules about these things AND not break existing implementations. They recognized that (a) and (b) were in existing implementations and were reasonable, and they chose not to break the existing implementations when writing the standard.

This is similar to the extremely unfortunate definition of the NULL macro. There were two existing styles of implementation (bare literal 0 and (void *) 0) and the Standard allows either style. Which means the NULL macro is not entirely safe to use in portable code.

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

#12

Post by bobmcnamara »

o11c wrote: post #3
bobmcnamara wrote: post #2

Ages ago I worked with a system where malloc(0) incremented a counter and returned -1. free(-1) decremented the counter. This way you could check for leaks :p

Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. On most platforms an implementation could just return adjacent addresses from the top half of the address space. On 32-bit platforms it doesn't take long to run out of such address space however, and you don't want to waste the space for a bitmap allocator. I suppose you could just use a counter for each 64K region or somethin…

> Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`.

I know I've seen that somewhere, but may I ask what standard you're referring to?

If I recall correctly, this was an archaic stackless microcontroller. The heap support was mostly a marketing claim.

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

#13

Post by bobmcnamara »

LPisGood wrote: post #10
o11c wrote: post #3

Earlier quoted context omitted.

Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. On most platforms an implementation could just return adjacent addresses from the top half of the address space. On 32-bit platforms it doesn't take long to run out of such address space however, and you don't want to waste the space for a bitmap allocator. I suppose you could just use a counter for each 64K region or somethin…

Noncompliant, but what could this reasonably impact?

> Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`.

I know I've seen that somewhere, but may I ask what standard you're referring to?

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

#14

Post by commandlinefan »

cjensen wrote: post #11
AaronDinesh wrote: post #5

Why should it be allowed to return a valid pointers anyways? Surely it should always return NULL?

There are three reasonable choices: (a) return the null pointer (b) return a valid unique pointer and (c) abort(). The point of the original C Standard was to make rules about these things AND not break existing implementations. They recognized that (a) and (b) were in existing implementations and were reasonable, and they chose not to break the existing implementations when writing the standard. This is similar to t…

> return a valid unique pointer

A pointer to what, though? If the requester asked for 0 bytes of memory, you'd either be pointing to memory allocated for another purpose (!) or allocating a few bytes that weren't asked for.

> This makes people unhappy for various reasons

I read through all the links trying to figure out what those reasons might be and came up empty, I'm still curious why anybody would expect or rely on anything except a null pointer in this instance.

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

#15

Post by o11c »

LPisGood wrote: post #10
o11c wrote: post #3

Earlier quoted context omitted.

Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. On most platforms an implementation could just return adjacent addresses from the top half of the address space. On 32-bit platforms it doesn't take long to run out of such address space however, and you don't want to waste the space for a bitmap allocator. I suppose you could just use a counter for each 64K region or somethin…

Noncompliant, but what could this reasonably impact?

Pointers are frequently used as keys for map-like data structures. This introduces collisions that the programmer can't check for, whereas NULL is very often special-cased.

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

#16

Post by TZubiri »

Joker_vD wrote: post #6
AaronDinesh wrote: post #5

Why should it be allowed to return a valid pointers anyways? Surely it should always return NULL?

For instance, because you are prohibited from passing NULL to e.g. memcpy and lots of other library functions from memory.h/string.h, even when you explicitly specify a size of 0. Another use was to use it to mint unique cookies/addresses, but malloc(1) works for this just as well.

Mmmmh, cookies

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

#17

Post by jmgao »

bobmcnamara wrote: post #12
o11c wrote: post #3

Earlier quoted context omitted.

Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. On most platforms an implementation could just return adjacent addresses from the top half of the address space. On 32-bit platforms it doesn't take long to run out of such address space however, and you don't want to waste the space for a bitmap allocator. I suppose you could just use a counter for each 64K region or somethin…

> Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. I know I've seen that somewhere, but may I ask what standard you're referring to? If I recall correctly, this was an archaic stackless microcontroller. The heap support was mostly a marketing claim.

C89: https://port70.net/%7Ensz/c/c89/c89-draft.html

If the size of the space requested is zero, the behavior is implementation-defined; the value returned shall be either a null pointer or a unique pointer.

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

#18

Post by tedunangst »

commandlinefan wrote: post #14
cjensen wrote: post #11

Earlier quoted context omitted.

There are three reasonable choices: (a) return the null pointer (b) return a valid unique pointer and (c) abort(). The point of the original C Standard was to make rules about these things AND not break existing implementations. They recognized that (a) and (b) were in existing implementations and were reasonable, and they chose not to break the existing implementations when writing the standard. This is similar to t…

> return a valid unique pointer A pointer to what, though? If the requester asked for 0 bytes of memory, you'd either be pointing to memory allocated for another purpose (!) or allocating a few bytes that weren't asked for. > This makes people unhappy for various reasons I read through all the links trying to figure out what those reasons might be and came up empty, I'm still curious why anybody would expect or rely…

You can copy from a zero sized pointer with memcpy, but not NULL.

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

#19

Post by fredoralive »

bobmcnamara wrote: post #12
o11c wrote: post #3

Earlier quoted context omitted.

Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. On most platforms an implementation could just return adjacent addresses from the top half of the address space. On 32-bit platforms it doesn't take long to run out of such address space however, and you don't want to waste the space for a bitmap allocator. I suppose you could just use a counter for each 64K region or somethin…

> Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. I know I've seen that somewhere, but may I ask what standard you're referring to? If I recall correctly, this was an archaic stackless microcontroller. The heap support was mostly a marketing claim.

Presumably the ANSI C standard or one of the later editions? They also cover the standard library as well as the language. (Presumably the bit about "Each such allocation shall yield a pointer to an object disjoint from any other object." if the random C99 draft I found via google is accurate to the final standard - I suppose you might question if this special use is technically an allocation of course).

Of course, microcontrollers and the like can have somewhat eccentric implementations of languages of thing and perhaps aren't strictly compliant, and frankly even standard compliant stuff like "int can be 16 bits" might surprise some code that doesn't expect it.

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

#20

Post by masfuerte »

bobmcnamara wrote: post #13
LPisGood wrote: post #10

Earlier quoted context omitted.

Noncompliant, but what could this reasonably impact?

> Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. I know I've seen that somewhere, but may I ask what standard you're referring to?

It's POSIX.

> Each [...] allocation shall yield a pointer to an object disjoint from any other object. The pointer returned points to the start (lowest byte address) of the allocated space. If the space cannot be allocated, a null pointer shall be returned. If the size of the space requested is 0, the behavior is implementation-defined: either a null pointer shall be returned, or the behavior shall be as if the size were some non-zero value, except that the behavior is undefined if the returned pointer is used to access an object.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/m...

Post reply on HN