On 19/05/18 01:17 PM, D. Hugh Redelmeier via talk wrote:
| 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.
Primarily, it's a trivial example that everyone will understand. It is also an example of a bug and people trying to code /in terms of the bug/. Arguably not a good thing to do ...
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?
Some people don't have the source to their programs, so they can get stuck using an old interface, and be unable to recompile if the library changed. We had that with linker records at Honeywell: we could add new ones, and even require people to set a particular flag to force them to be still honored, but we didn't succeed in taking the one I was involved in out. Others removals went fine, so no-one seemed to have been wedged by them. I used the example in part to illustrate that there are tradeoffs, and also "religious" debates over whether something is a bug or a feature. There's one religious debate going on right now about closures in Go. Everyone who has been caught by the bug splits into one of two camps. One group says "fix it, it doesn't break any programs that have coded around the bug". The other group says "It's a feature. I had code around it, and everyone else should have to, too" That one's an example that argues for not supporting old interfaces, while the lost-code example argues for retaining them even when it's to enable deliberately doing a wrong thing.
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. Yes. For a language to advance, it has to be able to stop supporting old interfaces. Thus my snarky comment about coding in terms of a bug (;-))
Doing so may take a deep text-to-text transformer like "go fix", and it may take a sliding window of how old an interface can be, with occasional special case like the Honeywell GCOS linker's -allow-old-call-frames option.
I find it disgraceful that the transition from Python 2 to Python 3 is still a thing 10 years on. IMHO, they need a "python fix" program that transforms at the parse tree level, not just textually like 2to3 and 3to2 do.
--dave [There's a ton of interesting stuff in the David J Brown paper] -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain