mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Eleanor Bartle <eleanor@eleanor-nb.com>
Cc: Markus Wichmann <nullplan@gmx.net>, musl@lists.openwall.com
Subject: Re: [musl] Care about Symbol Namespacing?
Date: Wed, 15 Nov 2023 10:20:43 -0500	[thread overview]
Message-ID: <20231115152042.GX4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <5926c9d9-083e-4ee4-8c87-3f58aca2f428@app.fastmail.com>

On Wed, Nov 15, 2023 at 05:11:02PM +1100, Eleanor Bartle wrote:
> That's about it, yes. Though I will point out that Solaris supports
> LD_PRELOAD just fine -- the preloads just need to be marked as such.
> For calls between components there's really no way to structurally
> prevent interposition.
> 
> The benefit is faster inter-component symbol lookup, as well as
> sanity in the face of an _accidental_ name collision. The tradeoff
> is complexity of specification to support all existing use cases. If
> the standard were being designed from scratch it might not be too
> hard to accomplish cleanly; to graft on to an existing model is a
> nightmare.

If your intent is just to check for accidental name collision, you can
do this with diagnostic tooling not runtime semantic changes. And this
is what you want to know, and what I mean by static linking being
first-class. Making accidental name collisions transparently work
would make it so things break horribly when someone decides they want
to static link, and you as the author don't realize this because you
never tried static linking. What's better would be running a tool that
basically just does ldd and looks for multiple definitions of the same
symbol, and tells you "you've got something wrong! you need to fix
that!"

Rich

  reply	other threads:[~2023-11-15 15:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14  2:32 Eleanor Bartle
2023-11-14  3:10 ` Rich Felker
2023-11-14  3:33   ` Eleanor Bartle
2023-11-14 15:35     ` Markus Wichmann
2023-11-15  6:11       ` Eleanor Bartle
2023-11-15 15:20         ` Rich Felker [this message]
2023-11-28  5:17           ` Fangrui Song
2023-11-29 13:45             ` Carlos O'Donell
2023-12-03 15:54               ` Fangrui Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231115152042.GX4163@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=eleanor@eleanor-nb.com \
    --cc=musl@lists.openwall.com \
    --cc=nullplan@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).