Love it, I’ve added it to the post 🙂

return “false”;

The threads could all read/modify this flag directly, so declaring it ‘volatile’ wouldn’t provide necessary atomicity guarantees (this revelation was described by one co-worker as feeling like having their religious beliefs challenged). Fortunately, we compile in C++11 code, so std::atomic was available.

The Fs::Value class is meant to allow internal values in our app to be exposed for read (and sometimes write) access via a virtual filesystem, sort of like Linux sysfs for a userspace app. The major sin was that the API didn’t have an overload for Register() that accepted a bool*, so somebody quite a while back decided uint16_t* was close enough and shoved it in through that interface (even though that sort of cast is UB). Since the pointer passed in was kept and used for servicing read/write operations from the virtual filesystem, this could have broken in all sorts of ways (e.g. memory corruption since uint16_t and bool are different sizes on our platform or even resulting in a bool that evaluated as both true and false or neither true nor false: https://stackoverflow.com/questions/4518951/engineered-bool-compares-equal-to-both-true-and-false-why).