> Others will return what's called a "null pointer", a special pointer that will crash your program if you try to read or write the memory it points to. This is not strictly true, it depends on the environment you're using. Some older operating systems and some modern embedded systems have memory mapped at the zero address.
If we’re gonna be pedantic, isn’t memory mapping itself an optional property? Ie you can have a pointer to 0x00..00 refer to the actual physical bytes at that address, without any mapping, no?
Memory Allocation
171–180 of 182 posts
Re: Memory Allocation
#172> Others will return what's called a "null pointer", a special pointer that will crash your program if you try to read or write the memory it points to. This is not strictly true, it depends on the environment you're using. Some older operating systems and some modern embedded systems have memory mapped at the zero address.
If we’re gonna be pedantic, isn’t memory mapping itself an optional property? Ie you can have a pointer to 0x00..00 refer to the actual physical bytes at that address, without any mapping, no?
On the other hand, most people expect the usual layout that grows from zero upwards. CPU designers are people, too, and make similar assumptions about layout and operation of memory (if they have to), which then affect systems that use their processors. Also, with all its compatibility, C still presumed certain class of hardware. It was not invented as a language for every microprocessor and microcontroller and each odd memory model, the microcontroller evolution was instead affected by alignment with coding in C.
This ugly hack (using the same object to hold the address value that can be operated on, and its own validity information) might be the most well known.
Re: Memory Allocation
#173Earlier quoted context omitted.
So basically garbage collection via just terminating and letting the OS handle it?
Yes, this is what Ur/Web does albeit this is limited to Web Server requests. I'd argue all programs could be short lived and memory management becomes a matter of sizing program's scope/role to the amount of memory you can greedily consume. Certainly many sorting program (for e.g.) can leak until they terminate. Then, cheap instantiation and communication between programs.
Re: Memory Allocation
#174Earlier quoted context omitted.
Really appreciate you taking the time to write this, thank you. I tried a couple of different ways to introduce the stack and the heap but it always felt like it made the post too long and complicated. In the end I decided to take a pure, idealistic view of memory in order to focus on the algorithms used to pack allocations effectively. You can see some of my abandoned efforts as HTML comments in the post :D Introduc…
Is it really necessary to use hexadecimal at all in the article? Decimal works just fine for pointers, it's just not conventionally used.
1. It's what people are going to be exposed to in any material outside of this post. 2. Within this post, it helps distinguish between pointers and sizes/values.
Re: Memory Allocation
#175Earlier quoted context omitted.
I think it's a nice little example for "Explorable Explanations", a term coined by Bret Victor in his eponymous essay[1] from 2011. [1]: http://worrydream.com/ExplorableExplanations/
I've been admiring this trend since I started seeing these kinds of essays posted here, and felt motivated to start collecting them in a curated list[0]. Happy to accept new entries or volunteers to help maintain it! [0] https://github.com/BHSPitMonkey/awesome-explanations
Re: Memory Allocation
#176When writing C, I tend to avoid calling malloc and free directly. * https://github.com/DaveJarvis/mandelbrot/blob/master/memory.... I then apply this same principle of "opening" and "closing" structures throughout the application. Generally, I can quickly verify that the calls are balanced: * https://github.com/DaveJarvis/mandelbrot/blob/master/threads... What's nice about this pattern is that the underlying implemen…
As a very minor point, calling free(NULL) is well-defined and safe so there is no need for the if-statement in memory_close(). This is very clearly stated in the manual page [1] for instance:
If ptr is a null pointer, no action shall occur.
Re: Memory Allocation
#177Re: Memory Allocation
#178Re: Memory Allocation
#179Earlier quoted context omitted.
I've been admiring this trend since I started seeing these kinds of essays posted here, and felt motivated to start collecting them in a curated list[0]. Happy to accept new entries or volunteers to help maintain it! [0] https://github.com/BHSPitMonkey/awesome-explanations
Would you be open to suggestions? Off the top of my head, there's Explorable Explanations from https://ncase.me and, while not as educational, The Space Elevator on https://neal.fun
Re: Memory Allocation
#180When writing C, I tend to avoid calling malloc and free directly. * https://github.com/DaveJarvis/mandelbrot/blob/master/memory.... I then apply this same principle of "opening" and "closing" structures throughout the application. Generally, I can quickly verify that the calls are balanced: * https://github.com/DaveJarvis/mandelbrot/blob/master/threads... What's nice about this pattern is that the underlying implemen…
Interesting. As a very minor point, calling free(NULL) is well-defined and safe so there is no need for the if-statement in memory_close(). This is very clearly stated in the manual page [1] for instance: If ptr is a null pointer, no action shall occur. [1]: https://man7.org/linux/man-pages/man3/free.3p.html
Probably showing my age. SunOS 4, PalmOS, and 3BSD reputedly crashed. (There were also double free exploits back in 1996.)
This further illustrates my point, though: Removing the NULL check is a single conditional to remove, as opposed to littering the free + guard everywhere. In effect, by isolating duplicated pieces of logic, it keeps possibilities open.