Original HN announcement/discussion [https://news.ycombinator.com/item?id=8974024]. CFLAGS additions produce smaller binaries. HelloWorld in 608 bytes (i386) and 792 bytes (x86_64). An example of sbrk/brk provided in the test folder.
I agree that sbrk/brk are nearly deprecated. But not all allocators I studied use mprotect or mmap. Most reference material (old OS books & blogs) still refer to sbrk/brk and/or malloc when discussing reference counters or garbage collectors. And Linux has a nice gotcha (see the Linux notes here[1]) in its implementation of the sys_brk syscall. It matches neither of the interfaces described for sbrk or brk exactly that most people are familiar with.
For me, however, I have a personal goal to show how to implement the basic newlib porting requirements [2].
A flat address space is the future. You don't need virtual memory when a flat address space can hold all memory addresses for all processes as it does now with 64-bit processors.
Could you explain how virtual memory makes a process more secure? My intuition is that it would be another source of contention to manage (like CPU, RAM, IO, etc).
Maybe you're considering non-sequential address space an improvement for security. That I could see. ASLR would be another, which, you can see the effect of by multiple runs of t/_end.exe in rt0.
And yes, I would expect mmap to be used in most modern systems. OS X, for instance, just emulates sbrk with a large static buffer, and it has no actual effect on the page tables.
