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

Malloc Never Fails (2012)

scvalex.net

Post reply on HN
Print view View original

161–165 of 165 posts

Re: Malloc Never Fails (2012)

#161

Post by kazinator »

simias wrote: post #70
mehrdadn wrote: post #63

Earlier quoted context omitted.

> If you have some specific part of the C standard in mind please do tell See here: https://news.ycombinator.com/item?id=20145604 Also note the POSIX standard: Upon successful completion with size not equal to 0, malloc() shall return a pointer to the allocated space. If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. Otherwise, it shall return a null…

Thank you for your reply but I still don't buy it. As far as the program is concerned it is returned a memory block, what this "memory" is effectively behind the scenes is none of the standard's business. As long as the implementation manages to maintain the illusion it's perfectly fine AFAIK. The problem is when this breaks down and the kernel realizes that it can no longer maintain the masquerade. If at this point…

If a tiny, strictly conforming ISO C program obtains a tiny block of memory from malloc (like a few hundred bytes) and crashes when trying to initialize it, that is almost certainly a non-conforming ISO C implementation. The reason is that the implementation cannot support even one single program that exercises each of the implementation limits.

See 5.2.4.1 in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf

However, it's true that not any old instance of this malloc problem demonstrates such a nonconformance. If it happens in a large program that has allocated gobs of memory, then no.

Basically if the system is low on memory that it can no longer support the execution of a small C program with modest memory use, then it becomes nonconforming.

However, the mere property that memory can be doled out by malloc which might later not be used doesn't make it ipso facto nonconforming.

Moreover, a system with any kind of memory management (including management that earnestly reports null for "out of memory") can be come a nonconforming C implementation if it is low on memory.

Re: Malloc Never Fails (2012)

#163

Post by brianfen »

mehrdadn wrote: post #146
klodolph wrote: post #81

Earlier quoted context omitted.

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.

Re: Malloc Never Fails (2012)

#164

Post by foo101 »

mehrdadn wrote: post #144
klodolph wrote: post #79

Earlier quoted context omitted.

Allocated "space", i.e., virtual memory space. Malloc allocates virtual memory space, not physical RAM.

C has no notion of virtual memory. If memory is allocated for you that means you can read and write to it.

There is no guarantee offered by the standard that you must be able to read and write to memory allocated by malloc(). What if the memory was allocated and just a split second later, the physical RAM burnt out due to overheating? How is the standard supposed to guarantee reading and writing to it then?

Both the hardware burning after memory allocation and lack of availability of physical memory after memory allocation are outside the scope of the standard. The standard says nothing about them. A C program can fail in these scenarios without violating the standard.

Re: Malloc Never Fails (2012)

#165

Post by cheerlessbog »

cesarb wrote: post #154
cheerlessbog wrote: post #98

Earlier quoted context omitted.

Most of my programming experience is in Windows. Can someone briefly explain why it doesn't seem to need an OOM killer? Is it happier to page? Or it always commits on allocation? Or something else.

AFAIK, Windows always commits on allocation, growing the swap file if necessary.

Why doesn't Linux do this?
Post reply on HN