This list is of no particular orderning, neither of importance nor chronological. It is written in the order in which I remembered them as I was writing this.
Pointers and Memory - Stanford CS Library
This link contains another link to a pdf of a very, very, very thorough explanation of pointers in C.
It’s not necessarily interesting if you already understand pointers in general, but it is a relatively short read–only 31 pages!–for the depth of the material it covers.
As a bonus, it’s also written by the same person who wrote the very well-written and short C manual, Essential C: Nick Parlante.
Job Control Commands in Linux
This link explains the use of the commands fg, bg, jobs, and Ctrl-Z in Linux.
I think it’s interesting because this is a direct user interface to the OS concept of swapping and context switching mentioned in OSC chapter 9., entirely to the user’s access.
Fun sidenote: I actually found out about these commands by accident when I was transitioning to learn how Linux works and pressed Ctrl-Z by muscle memory.
PIE in action
This link is a very, very well-written answer demonstrating the use of PIE–Position Independent Executable–and ASLR in action on an actual C program.
If you’ve come across the topic of memory management and pointers, you might’ve heard of the concept of ASLR, i.e. Address Space Layout Randomization, which results in inspecting pointer values to return basically gibberish; quite useful in mitigating the risk of buffer overflow attacks.
But some of us might have tried to actually print out memory locations and return with basically normal, very expectable memory locations.
Does this mean PIE isn’t enabled?
Well, no, it actually just means that we’re printing out virtual memory instead of physical memory, but it does raise an interesting question: when is PIE/ASLR not used, if it seems to obviously be advantegeous not just for security but for general portability?
Position Independent Executables
This link is a companion piece to the link above, for a more theoretical look into PIE as it relates to MMUs and address mapping between the CPU and the physical memory, with additional examples.
Here the author notes a very interesting reason for the question we have before, i.e. when does one not want PIE?
And the simple reason is when ASLR at all is not enabled, which makes PIE not very useful.
Hehe, very anticlimactic, but that’s about the bottom of the rabbit hole.
Malloc Tutorial
This link provides a short tutorial on how to reimplement malloc, free, and calloc as specified–somewhat–in the C standard.
I think it’s interesting because the concept itself–reimplement malloc–was, to my knowledge, originally a joke about how programming interview questions will become increasingly insane, from fizzbuzz to inverting binary trees to this.
What surprised me is how relatively tame the concept is as a whole. It’s not easy, but not insanely technical either, from a joke’s perspective.
alloc.h
This is a short reference documentation to the alloc.h header file that–if I understand correctly–comes with C compilers for MS-DOS.
In it one will find redefined malloc, free, and some nonstandard procedures like alloca, etc.
It’s considered “deprecated” for most builds today unless you’re one of those weird people who uses MS-DOS for nostalgia purposes.
I think it’s interesting mostly from a funny coincidence perspective: this and conio.h are those few magic terms that people learning C from old MS-oriented textbooks or tutorials will find which will first introduce them to the concept of deprecated libraries specifically due to operating system specifications.
That is, unless they never find forum posts of people calling each other stupid for not knowing what they are and why they shouldn’t be used.
Windows 95 Defrag
This is a video demonstration of the Windows Disk Defragmenter, also known as the Microsoft Drive Optimizer, which is a Windows tool used to mitigate the issue of fragmentation in Windows PCs.
There’s absolutely nothing educational about this video, but I included it because the topic of fragmentation reminded me of something an old millennial once told me about old Windows PCs: the experience of watching a little boxes blink on the GUI of the disk defragmenter while it is working is something akin to religious Zen meditation as a child.
Unfortunately I never experienced this because the only thing I used PCs for as a child was writing in MS Word for assignments.
What’s the advantage of little endian?
This link provides several answers to the question of the advantages of little endianness.
The topic itself was mentioned only briefly in the slides and was discussed in class as well as other previous classes like POK.
However the specific advantages itself was never made clear, at least to me, beyond the classic parallelizing of addition ops with operand fetches in very small 8-bit systems.
Some answers here though intrigue me, like the idea of little endianness being advantegeous in making casting basically polymorphic since all addresses are the same length, etc.
Get the most out of the linker map file
This link provides a top-down exploration of .map files and how to understand them.
So if you’re like me and you’re also incredibly newbie and you’ve also seen the slides for this week, you might be surprised to see the files generated with the extension .map, and you have no idea what it is.
And this is it: a symbol table.
Very simple, but also very interesting, because for most high-level programmers the idea of needing a symbol table for the purposes of debugging might not be that big of a deal, but it is very much so for people working close to the metal.
And while a counterpart does exist for people working with systems using sophisticated IDEs, it’s not part of the default tooling of high-level, abstract, generalized computing; at least as far as I know.
When to use dynamic linking and static linking
This link provides a very short intro to the idea of dynamic vs static linking, though the backdrop is specific to the AIX operating system.
When I was looking into this topic, I kept running into either non-answers that boil down to “it depends!” or incredibly pedantic arguments about Snap, Flatpak, etc.
This one is interesting to me because it includes this little quote:
One method of determining whether your application is sensitive to the shared-library approach is to recompile your executable program using the nonshared option.
Of which, I, in profound stupefaction, realized that I had never even thought about that as a solution to testing whether or not some software actually needs to be statically or dynamically linked.
That’s it for now. またね！