It's certainly a humorous anecdote and arguably a practical solution to the problem. But when the mission of the code expands beyond the original use case, thi

It's certainly a humorous anecdote and arguably a practical solution to the problem. But when the mission of the code expands beyond the original use case, this element might be lost. It's best to encode these limitations/constraints into the design of the program, whenever possible. However for this case I cannot imagine how to do that. When that's impossible, it's ideal to advertise these limitations as a design feature coupled with the intended use cases. Therein lies the only hope of discovering this before it causes problems. These days, the vast, vast majority of our code can and should undergo unit testing and have sanitizer tests enabled for that unit testing. We should be extremely cautious about whitelisting/bypassing those checks (but at least those are more explicit signals).