Category Archives: _Twitter Archive 🐤
Twitter’s length limit is deceptive. At a glance, it suggests that writing tweets should be easy and quick. This is true for superficial tweets, but does not mean all tweets are written quickly and with little effort.
Twitter is actually a platform for concise writing, and writing concisely is harder than writing verbosely. There are certain tweets I spend a lot of time on and it’s shame to have them get lost in my feed. So I’m storing them here.Continue reading
Tips for reading the Linux kernel
Tips for effective technical presentations
Wrote a twitter thread about this:
Don’t confuse std::move and std::forward
This was a pretty interesting buggy scenario I found while reading the clang-tidy checks. If you’re writing a function that takes a forwarding reference (what looks like an rvalue reference, but whose type is a template argument), you need to be careful to not call
std::move on it. You need to make sure to call
std::forward instead. Otherwise, you might accidentally trigger a move on an object passed by a caller! This would be confusing, since their object would be moved from, and they never explicitly called
std::move on it.
Getting bit by unique_ptr
I got bit by
unique_ptr when implementing a linked list today. You need to be careful to manually
unique_ptr before resetting or you might accidentally free the entire list. This comes up when doing insertions and stuff like that.
You can use /proc/*/mem to bypass memory protections
Filmed some screencasts today explaining some interesting behavior with
/proc/self/mem — you can use it to write to unwritable memory (including the text of libc!).
Read bits are not enforced for memory mappings
Filmed a screencast exploring some neat mmap behavior — read bits are not enforced for memory mappings. This is because the underlying x86 page table entries have a single bit to toggle between “Read” and “Read/Write”.
macOS has a native memory leak checker
Reproducing a GCC 8.1 ABI compatibility bug
I was reading about GCC and noticed this very suspicious warning line about an accidental compatibility break: https://gcc.gnu.org/gcc-8/changes.html
I thought it would be interesting to reproduce this. I reprodcued this specific scenario they outline and compiled two translations units, one with GCC 8.1, one with an earlier version (GCC 7) and observed the segfault that happens when two incompatible calling conventions interact with each other.