From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14608 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: About those weak aliases Date: Tue, 3 Sep 2019 08:08:55 -0400 Message-ID: <20190903120855.GW9017@brightrain.aerifal.cx> References: <20190902190359.GA6472@voyager> <20190902201009.GV22009@port70.net> <20190902230118.GT9017@brightrain.aerifal.cx> <20190903101339.GX22009@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="56446"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14624-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 03 14:09:11 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1i57cV-000Ea8-KW for gllmg-musl@m.gmane.org; Tue, 03 Sep 2019 14:09:11 +0200 Original-Received: (qmail 20372 invoked by uid 550); 3 Sep 2019 12:09:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 20353 invoked from network); 3 Sep 2019 12:09:08 -0000 Content-Disposition: inline In-Reply-To: <20190903101339.GX22009@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14608 Archived-At: On Tue, Sep 03, 2019 at 12:13:39PM +0200, Szabolcs Nagy wrote: > * Rich Felker [2019-09-02 19:01:18 -0400]: > > On Mon, Sep 02, 2019 at 10:10:10PM +0200, Szabolcs Nagy wrote: > > > (could be a strong alias, weakness of public api symbols > > > doesn't matter, you can only observe the difference by > > > getting a link error when static linking a conflicting > > > definition, but that is non-standard: when the symbol is > > > reserved for the implementation user code must not use it) > > > > I don't follow here. There are very few if any places where strong > > alias would be a valid substitute for weak. Where weak aliases provide > > dummy implementations of functionality that's only needed if something > > else is linked, strong would be a link error if both were linked. > > Where weak aliases are used because the identifier being defined is > > reserved to the application in some or all standard profiles, a strong > > alias would produce a link error if the application actually made use > > of its reservation and the file defining the alias got linked (and the > > whole point is that this can and does happen). > > you are right. sorry No problem. It's informative for uncovering if there are such cases and what they're for. I think the only places strong aliases would be okay is when the alias is providing a public interface and it's in the same namespace (or a more restrictive implementation namespace) as the symbol it's aliasing. These are mostly glibc ABI-compat symbols where the glibc ABI had __-prefixed versions of some public function as a public ABI (e.g. the __-prefixed versions of the 'xlocale' functions, __isoc99_*scanf, __getdelim; maybe nothing else). Rich