News for hackers. Stuff that matters.
Re:Once upon a time, memory allocators made sense by jstanley on Monday January 18, 2016 @12:18PM (#10925509)
That's not right: http://pastebin.com/aA7dasDx

  jes@themisto:~$ cc -o alloc alloc.c
  jes@themisto:~$ ulimit -v 100000
  jes@themisto:~$ ./alloc
  malloc returned NULL after allocated 94227K
EDIT: Ubuntu 15.04, x86_64, Linux 3.19
Re:Once upon a time, memory allocators made sense by felixgallo on Monday January 18, 2016 @02:38PM (#10926386)
however, ulimit will only affect your process; if other processes consume enough RAM, you can still run out of pages while under the influence of ulimit.
Re:Once upon a time, memory allocators made sense by dfox on Monday January 18, 2016 @02:41PM (#10926407)
OK, mmap() will fail and thus malloc() will return NULL. The point is that you cannot rely on that. For example try what will happen with recursive functions that call alloca(1024).
Re:Once upon a time, memory allocators made sense by Patient0 on Monday January 18, 2016 @03:33PM (#10926712)
Sorry how is this relevant to heap allocation? alloca just allocates memory off the stack - it's literally just bumping the stack register by the number of bytes you requested (and hence it's freed when the stack pointer is reset on returning from the function call). Alloca should fail when your current thread runs out of stack space - which will generally be only a few megabytes. The total stack for a new thread is allocated from the heap at its creation, not during its execution and certainly not as part of a call to alloca.
Re:Once upon a time, memory allocators made sense by pjc50 on Monday January 18, 2016 @05:57PM (#10927636)
"malloc() won't fail"

"oh yes it does"

"oh no it doesn't"

demo of malloc failing

"alloca() won't fail!"

Stop moving the goalposts. Besides, alloca() tends to crash your program a lot sooner as stack allocation is usually very limited, especially in a shared-memory multithreading context. Hardly anyone uses alloca().