Hacker News Reader

Comment by mehrdadn | Hacker News Reader

Like, every part? It doesn't actually allocate the space requested, it doesn't indicate failure by returning NULL (or by any other reliable means for that matter)...

View on HN

I had a look, and the C standard doesn't actually say anything about indicating failure. Here is all it says about malloc:

> The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.

> The malloc function returns either a null pointer or a pointer to the allocated space.

I think it's certainly debatable whether overcommitting while lazily allocating counts as actually allocating.

> I had a look, and the C standard doesn't actually say anything about indicating failure.

> The malloc function returns either a null pointer or a pointer to the allocated space.

Uhm, either malloc returns a pointer to the allocated space, or it returns null. I don't see what's so complicated about this. There's no provision for "return a non-null pointer to unallocated space".

The malloc() function requests memory from the kernel using mmap(). If mmap() returns successfully, it means that the kernel is saying that the memory is allocated. So from malloc()'s perspective the memory allocation has been successful and it must return a non-null pointer to the caller. The standard does not require malloc() to distrust what the kernel said and try to actually write to that memory to double-check if there is any physical memory mapped to it or not. The standard also does not impose anything on the kernel. I see no section of the standard being violated here.

Section 7.22.3.1:

The order and contiguity of storage allocated by successive calls to the aligned_alloc, calloc, malloc, and realloc functions is unspecified. The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated). The lifetime of an allocated object extends from the allocation until the deallocation. Each such 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 is returned. If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

Section 7.22.3.4:

The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.

The standard literally could not care less if there's a kernel underneath. It doesn't care how malloc is implemented or what the kernel, if any, looks like "from its perspective". The perspective that has relevance is that of the caller of malloc. From your own quotes:

> The pointer returned if the allocation succeeds is suitably aligned so that [...]

> If the space cannot be allocated, a null pointer is returned.

If you use mmap and "from your perspective" that's considered success then it's your perspective that's faulty. The standard is literally telling you right here^ there are 2 possibilities: either you allocate the space and return a pointer to the space, or you don't and you return null. There is no third option of "space cannot be allocated but you return non-null anyway". That's quite literally the end of the story.

The space IS allocated, it's just that this space (virtual memory) is not backed by physical RAM.

Try telling that to the C standard. It has no notion of virtual or physical memory. If it's allocated that means you can read/write to it, end of story.

> It has no notion of virtual or physical memory.

Exactly! That's why once virtual memory is allocated, malloc() is allowed to consider the operation successful. The standard does not care at all whether it is virtual memory allocation or physical memory allocation. It is completely unspecified in the standard what sort of memory must be allocated. So no spec in the standard is being violated by returning non-null pointer for virtual memory allocation.

You can't be serious about "every part". This definitely does not violate section 1.1 which only talks about the scope of the standard. It also definitely does not violate 1.2 which talks about what is not within the scope of the standard.

So once again, can you cite the exact section number from the standard that you think is being violated here?

See reply to sibling comment.

There is a deep irony in folks choosing to implement one of the few things the C standard DOES clearly define by papering over it with an alternative memory model.

Ironically, it's a memory model that greatly reduces the performance of modern systems, and als impacts its safety.

Reply on news.ycombinator.com