<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 19/05/18 01:17 PM, D. Hugh
      Redelmeier via talk wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:alpine.LFD.2.21.1805191304110.20857@redeye.mimosa.com">
      <pre wrap="">| From: David Collier-Brown via talk <a class="moz-txt-link-rfc2396E" href="mailto:talk@gtalug.org"><talk@gtalug.org></a>

| 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
| <a class="moz-txt-link-freetext" href="https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/">https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/</a>

Interesting.  I haven't (yet) read references from the blog posting.

The example of memcpy with overlapped arguments is interesting.</pre>
    </blockquote>
    <br>
    Primarily, it's a trivial example that everyone will understand.<br>
    <br>
    It is also an example of a bug and people trying to code <i>in
      terms of the bug</i>.  Arguably not a good thing to do ...<br>
    <blockquote type="cite"
      cite="mid:alpine.LFD.2.21.1805191304110.20857@redeye.mimosa.com">
      <pre wrap="">
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?</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.  <br>
    <br>
    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"<br>
    <br>
    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.<br>
    <br>
    <blockquote type="cite"
      cite="mid:alpine.LFD.2.21.1805191304110.20857@redeye.mimosa.com">
      <pre wrap="">
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.</pre>
    </blockquote>
    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 (;-))<br>
    <br>
    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.<br>
    <blockquote type="cite"
      cite="mid:alpine.LFD.2.21.1805191304110.20857@redeye.mimosa.com">
      <pre wrap="">
I find it disgraceful that the transition from Python 2 to Python 3 is
still a thing 10 years on.</pre>
    </blockquote>
    IMHO, they need a "python fix" program that transforms at the parse
    tree level, not just textually like 2to3 and 3to2 do.<br>
    <br>
    --dave<br>
    [There's a ton of interesting stuff in the David J Brown paper]<br>
    <pre class="moz-signature" cols="72">-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
<a class="moz-txt-link-abbreviated" href="mailto:davecb@spamcop.net">davecb@spamcop.net</a>           |                      -- Mark Twain
</pre>
  </body>
</html>