>IMO you should assume that if the user changed them, they changed them
>for a reason.
The user could've changed them for whatever reason, he might not even know that my library uses them. My task is to ensure that my library works as expected in as many cases as possible.
Here's a simple example. Let's assume that I want to write a library that exports a single function 'table_maxkey', which is dedicated to finding the biggest numeric key value in a table. Test case looks like
local max_idx = table_maxkey({1,2,8}) -- should return '8'
So I prepare this library (we all know what will be inside), write a README.md, post it on Github, and there's this one user that tries to use it, tries to reproduce the case above and gets the return value of "42". Yes, he did what he did with his own hands, but it is my library that works improperly here. I do not comply to my own interface, see?
How do I fix it? Well, I can't write a disclaimer "this library only works properly with default implementations of all library functions", which would've been an all-around safest way to restore the compliance (in case I plan to add something in future, you know), but no one will use such library, right? Here's another idea, I might write "this library only works properly with default implementations of pairs and next library functions". Yes, that works like charm, but again, assume that I support and extend my library, add new interfaces which will eventually depend on all library functions. My disclaimer, once written properly, will probably be bigger than the code itself. Plus, I need either a handful of hand labor or some good automation to support the compliance.
>e.g. In C code you don't go around checking functions do what they're
>documented to do just in case someone used LD_PRELOAD.
I just googled "prevent dll spoofing" and got, quote, "About 77,800 results". Plus the unique content by keywords 'dll shimming', 'dll hijacking' and also linux/bsd/macos-specific content that is not googled by keyword 'dll', see for yourself. I think that's something to start with?
Igor A. Ehrlich
