[GTALUG] Sidebar re libraries
David Collier-Brown
davec-b at rogers.com
Sat May 19 15:01:29 EDT 2018
On 19/05/18 01:17 PM, D. Hugh Redelmeier via talk wrote:
> | From: David Collier-Brown via talk <talk at 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-complete-problem/
>
> 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 at spamcop.net | -- Mark Twain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20180519/038dcfe2/attachment.html>
More information about the talk
mailing list