Tag Archives: Twitter Archive

Evergreen tweets

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

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.

Continue reading

Getting bit by unique_ptr

I got bit by unique_ptr when implementing a linked list today. You need to be careful to manually release() the 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”.

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 reproduced 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.