From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28481 invoked from network); 15 Nov 2023 15:20:49 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 15 Nov 2023 15:20:49 -0000 Received: (qmail 9920 invoked by uid 550); 15 Nov 2023 15:20:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9876 invoked from network); 15 Nov 2023 15:20:44 -0000 Date: Wed, 15 Nov 2023 10:20:43 -0500 From: Rich Felker To: Eleanor Bartle Cc: Markus Wichmann , musl@lists.openwall.com Message-ID: <20231115152042.GX4163@brightrain.aerifal.cx> References: <946a873e-9c02-4cd2-9460-f6dfa3aa5028@app.fastmail.com> <20231114031026.GV4163@brightrain.aerifal.cx> <5926c9d9-083e-4ee4-8c87-3f58aca2f428@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5926c9d9-083e-4ee4-8c87-3f58aca2f428@app.fastmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Care about Symbol Namespacing? 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