| From: David Collier-Brown via talk <talk@gtalug.org> | It's notable that Linux numbers the interface, not the library. This came from | Multics, and was heavily used by Solaris and the glibc developers to avoid an | NP_complete problem of "how do I have two versions of something at the same | time?" More details that you ever wanted in | https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-comp... Interesting. I haven't (yet) read references from the blog posting. The example of memcpy with overlapped arguments is interesting. If I remember correctly, overlapping arguments was banned in about 1980. So the chances of C code being older than that is rather low these days. Less so code that is unmaintained. So using overapping is a bug. Do we really want to keep old libraries to support buggy code? In fact, the change to cause memcpy with overlap to fail may not be a change in the library, it may be a change in the compiler. Or a change in the compiler that compiled the library. If you think we need to support buggy code by freezing the library, there is no end to how far you can take that. No changes are possible. You might as well freeze your program in a VM and not fix ANY bugs. That seems to be The Container Way. A compromise is to support old interfaces when a library changes its contract in some way that is not backward compatible. Not the implicit contract, the written contract (i.e. documentation). That presumes that your documentation is up to snuff -- sadly not as common as it should be. I think code improves when it tracks the things it depends on. Look at C and its compilers: it has gotten much better at letting the programmer express intentions and detecting inconsistencies. Code that doesn't use those features is likely less reliable. I find it disgraceful that the transition from Python 2 to Python 3 is still a thing 10 years on.