From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14393 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: open64 and similar Date: Wed, 10 Jul 2019 18:43:01 -0400 Message-ID: <20190710224301.GZ1506@brightrain.aerifal.cx> References: 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="171333"; 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-14409-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 11 00:43:17 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 1hlLIz-000iUB-Lw for gllmg-musl@m.gmane.org; Thu, 11 Jul 2019 00:43:17 +0200 Original-Received: (qmail 15893 invoked by uid 550); 10 Jul 2019 22:43:14 -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 15871 invoked from network); 10 Jul 2019 22:43:13 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14393 Archived-At: On Wed, Jul 10, 2019 at 06:03:51PM -0400, Andrew Bell wrote: > musl does the following: > > #define open64 open > > This can cause an infinite loop for the following code: > > class Foo > { > public: > int open64() > { open(); } > }; > > Perhaps it would be better to supply open64 and have it call open, rather > than #define it? There are several other xxx64 functions also defined that > could cause problems with unfortunate code. The intent is that we're trying to prevent actual references to the legacy open64, etc. symbols while supporting code that's wrongly attempting to use them. At the time this was added, that was still a problem in lots of software; I don't know if it's since been fixed. Originally, the intent was that the symbols exist *only* as ABI, for ABI-compat loading of glibc-linked libs, and not as API that programs compiled against musl could use. However broken configure scripts checked for the symbol definition by linking a test program using a *fake* declaration of the symbol, without including the header, then wrongly picked up that it was available, and compiled wrong code later at compiel time due to implicit-function-declaration. So the macro redirections were added. I'd like it if we could remove this stuff entirely, except for the ABI-compat. Maybe it could be done by getting rid of the actual symbols and just putting magic in the dynamic linker to resolve them to the non-64 ones. Anyway, this is not the first time someone's hit a problem from it with C++, which is caused by GCC's unconditional (and wrong) definition of _GNU_SOURCE in C++ mode. So we really should try to find a reasonable fix... Rich