This is so true, probably even without "a sufficient number of users". I wrote lots of code generation stuffs for binding and networking and I've seen a good nu

This is so true, probably even without "a sufficient number of users". I wrote lots of code generation stuffs for binding and networking and I've seen a good number of people who always want to just hack into generated codes because it's easier than asking me nicely. Of course, I did put a very clear "DO NOT EDIT" headline for every single generated files. They just don't care. They just edit and commit. Unfortunately the team at the moment didn't have a tool or process to block them, like code review or CI. But even if we had that, I'm sure that they would find a creative way to circumvent that. Anyway, I could stop them only after making the generated code to somehow validate itself and ensuring it hard enough to understand and bypass. Also, there was another creative exploit of our in-house slab allocator like object pool. The contract was simple; if the client asks, it will return a new object handle, which is just a pointer with some metadata. And every time it needs to access object, it should explicitly fetch the object pointer with some utility function which performs very basic memory safety checks like dangling pointer or double free etc. I wasn't its designer and it's not perfect but it actually caught some potential bugs on earlier stages so probably gave us some value. Anyway these are tangential to the real story. One day someone found out that its implementation resembled a sort of linked list on a large array and technically you can go through those objects if you're willing to play with reinterpret_cast. They decided to exploit that for "an efficient object query" and did it secretly. Obviously they didn't have all the handles, so safety checks are bypassed. This seemed to work for most cases because the code checked a tombstone bit, a part of object metadata rather than handle metadata. But for some case, an object could be released and a new object takes that memory place during the iteration (it's multi threaded) and this caused a number of subtle memory bugs since the object access was done out of iteration context. Yeah, library writers might deserve the right to break its clients if they ignores the contract. But I just wanted to say that sometime, it could be inevitable if the job's done as your means of livelihood and in that case you probably want to keep those creative people in your mind when you design your library. That probably won't stop them, but at least you will be less shocked by finding out their sole existence...