From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4883 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.linux.lib.musl.general Subject: fopen64 and friends as aliases Date: Tue, 15 Apr 2014 06:59:46 -0700 Message-ID: <20140415065946.dc30d64f61e5ec441c34ffd4f788e58e.ffe7ab07f9.wbe@email22.secureserver.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1397570417 25752 80.91.229.3 (15 Apr 2014 14:00:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Apr 2014 14:00:17 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4887-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 15 16:00:09 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wa3u6-0001bm-TA for gllmg-musl@plane.gmane.org; Tue, 15 Apr 2014 16:00:03 +0200 Original-Received: (qmail 3644 invoked by uid 550); 15 Apr 2014 14:00:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3636 invoked from network); 15 Apr 2014 14:00:00 -0000 X-SID: qDzn1n0022YkKj001 X-Originating-IP: 71.206.170.124 User-Agent: Workspace Webmail 5.6.48 Xref: news.gmane.org gmane.linux.lib.musl.general:4883 Archived-At:

Greetings,

I could not find in the archi= ves any discussion of the above topic, and was therefore wondering: would i= t be possible to have fopen64 and friends (fseeko64, ftello64, tmpfile64) a= s aliases of the non-prefixed functions, rather than having them #define'd = as synonyms? This will make most of the musl-llvm patch unnecessary, = and could probably help with other packages as well.

Kind regards,

From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4884 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: fopen64 and friends as aliases Date: Tue, 15 Apr 2014 10:21:06 -0400 Message-ID: <20140415142106.GX26358@brightrain.aerifal.cx> References: <20140415065946.dc30d64f61e5ec441c34ffd4f788e58e.ffe7ab07f9.wbe@email22.secureserver.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1397571691 17606 80.91.229.3 (15 Apr 2014 14:21:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Apr 2014 14:21:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4888-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 15 16:21:24 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wa4Eh-0006WC-UD for gllmg-musl@plane.gmane.org; Tue, 15 Apr 2014 16:21:20 +0200 Original-Received: (qmail 20308 invoked by uid 550); 15 Apr 2014 14:21:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20290 invoked from network); 15 Apr 2014 14:21:18 -0000 Content-Disposition: inline In-Reply-To: <20140415065946.dc30d64f61e5ec441c34ffd4f788e58e.ffe7ab07f9.wbe@email22.secureserver.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4884 Archived-At: On Tue, Apr 15, 2014 at 06:59:46AM -0700, writeonce@midipix.org wrote: > Greetings, > I could not find in the archives any discussion of the above topic, and > was therefore wondering: would it be possible to have fopen64 and friends > (fseeko64, ftello64, tmpfile64) as aliases of the non-prefixed functions, > rather than having them #define'd as synonyms? This will make most of the > musl-llvm patch unnecessary, and could probably help with other packages > as well. > Kind regards, > zg For some of them like stat64, the #define is necessary anyway since there is a struct that also needs to be mapped. So it's not so simple. In any case, the aliases already exist for binary compatibility, but some of them would be masked by these defines even if we declared them in the public headers. Really what you're asking for is just a workaround of a nonsensical bug in llvm, which should just be fixed. There is no excuse for the hack they're doing with namespaces; instead the names should just be properly prefixed to avoid clashing. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4885 Path: news.gmane.org!not-for-mail From: "writeonce@midipix.org" Newsgroups: gmane.linux.lib.musl.general Subject: Re: fopen64 and friends as aliases Date: Tue, 15 Apr 2014 15:03:54 -0400 Message-ID: <534D829A.8030808@midipix.org> References: <20140415065946.dc30d64f61e5ec441c34ffd4f788e58e.ffe7ab07f9.wbe@email22.secureserver.net> <20140415142106.GX26358@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1397588660 16390 80.91.229.3 (15 Apr 2014 19:04:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Apr 2014 19:04:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4889-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 15 21:04:13 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wa8eT-00037C-1g for gllmg-musl@plane.gmane.org; Tue, 15 Apr 2014 21:04:13 +0200 Original-Received: (qmail 26547 invoked by uid 550); 15 Apr 2014 19:04:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26536 invoked from network); 15 Apr 2014 19:04:11 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: <20140415142106.GX26358@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4885 Archived-At: On 04/15/2014 10:21 AM, Rich Felker wrote: > On Tue, Apr 15, 2014 at 06:59:46AM -0700, writeonce@midipix.org wrote: >> Greetings, >> I could not find in the archives any discussion of the above topic, and >> was therefore wondering: would it be possible to have fopen64 and friends >> (fseeko64, ftello64, tmpfile64) as aliases of the non-prefixed functions, >> rather than having them #define'd as synonyms? This will make most of the >> musl-llvm patch unnecessary, and could probably help with other packages >> as well. >> Kind regards, >> zg > For some of them like stat64, the #define is necessary anyway since > there is a struct that also needs to be mapped. So it's not so simple. > In any case, the aliases already exist for binary compatibility, but > some of them would be masked by these defines even if we declared them > in the public headers. > > Really what you're asking for is just a workaround of a nonsensical > bug in llvm, which should just be fixed. There is no excuse for the > hack they're doing with namespaces; instead the names should just be > properly prefixed to avoid clashing. I understand. In that case, and for those functions that do not require an extra structure mapping, what is the advantage of #define fopen64 fopen over FILE *fopen64 (const char *__restrict, const char *__restrict); If the weak alias is already there anyway, then using the latter should only "penalize" (by adding a reference to the extra symbol) those apps/libs that use fopen64 in the first place. Is that correct? > > Rich > > From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4886 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: fopen64 and friends as aliases Date: Tue, 15 Apr 2014 15:15:35 -0400 Message-ID: <20140415191535.GB26358@brightrain.aerifal.cx> References: <20140415065946.dc30d64f61e5ec441c34ffd4f788e58e.ffe7ab07f9.wbe@email22.secureserver.net> <20140415142106.GX26358@brightrain.aerifal.cx> <534D829A.8030808@midipix.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1397589355 27372 80.91.229.3 (15 Apr 2014 19:15:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Apr 2014 19:15:55 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4890-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 15 21:15:49 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wa8pf-0001Fk-SM for gllmg-musl@plane.gmane.org; Tue, 15 Apr 2014 21:15:47 +0200 Original-Received: (qmail 1948 invoked by uid 550); 15 Apr 2014 19:15:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1938 invoked from network); 15 Apr 2014 19:15:46 -0000 Content-Disposition: inline In-Reply-To: <534D829A.8030808@midipix.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4886 Archived-At: On Tue, Apr 15, 2014 at 03:03:54PM -0400, writeonce@midipix.org wrote: > On 04/15/2014 10:21 AM, Rich Felker wrote: > >On Tue, Apr 15, 2014 at 06:59:46AM -0700, writeonce@midipix.org wrote: > >> Greetings, > >> I could not find in the archives any discussion of the above topic, and > >> was therefore wondering: would it be possible to have fopen64 and friends > >> (fseeko64, ftello64, tmpfile64) as aliases of the non-prefixed functions, > >> rather than having them #define'd as synonyms? This will make most of the > >> musl-llvm patch unnecessary, and could probably help with other packages > >> as well. > >> Kind regards, > >> zg > >For some of them like stat64, the #define is necessary anyway since > >there is a struct that also needs to be mapped. So it's not so simple. > >In any case, the aliases already exist for binary compatibility, but > >some of them would be masked by these defines even if we declared them > >in the public headers. > > > >Really what you're asking for is just a workaround of a nonsensical > >bug in llvm, which should just be fixed. There is no excuse for the > >hack they're doing with namespaces; instead the names should just be > >properly prefixed to avoid clashing. > > I understand. In that case, and for those functions that do not > require an extra structure mapping, what is the advantage of > > #define fopen64 fopen > > over > > FILE *fopen64 (const char *__restrict, const char *__restrict); > > If the weak alias is already there anyway, then using the latter > should only "penalize" (by adding a reference to the extra symbol) > those apps/libs that use fopen64 in the first place. Is that > correct? There are three main advantages in my mind: 1. Lack of an extra set of prototypes that might need to be correct and which might not get tested well. 2. Avoiding putting references to the nonsense "64" symbols in the resulting binaries, so that the "64" symbols remain part of the ABI-compat layer (which could, in theory, be optional at build time somewhere in the future) rather than part of the public libc API. 3. Consistency: due to the need for #define stat64 stat (and perhaps others like this), using separate prototypes for the "64 functions would result in inconsistency in the binaries using them; some symbols would be referenced in the "64" version and others wouldn't. (And likewise, the "llvm bug" would manifest for some of them but not others.) Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4887 Path: news.gmane.org!not-for-mail From: "writeonce@midipix.org" Newsgroups: gmane.linux.lib.musl.general Subject: Re: fopen64 and friends as aliases Date: Tue, 15 Apr 2014 15:38:00 -0400 Message-ID: <534D8A98.60708@midipix.org> References: <20140415065946.dc30d64f61e5ec441c34ffd4f788e58e.ffe7ab07f9.wbe@email22.secureserver.net> <20140415142106.GX26358@brightrain.aerifal.cx> <534D829A.8030808@midipix.org> <20140415191535.GB26358@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1397590712 16502 80.91.229.3 (15 Apr 2014 19:38:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Apr 2014 19:38:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4891-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 15 21:38:25 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wa9BY-0002IB-H3 for gllmg-musl@plane.gmane.org; Tue, 15 Apr 2014 21:38:24 +0200 Original-Received: (qmail 13474 invoked by uid 550); 15 Apr 2014 19:38:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13463 invoked from network); 15 Apr 2014 19:38:23 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: <20140415191535.GB26358@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4887 Archived-At: On 04/15/2014 03:15 PM, Rich Felker wrote: > On Tue, Apr 15, 2014 at 03:03:54PM -0400, writeonce@midipix.org wrote: >> On 04/15/2014 10:21 AM, Rich Felker wrote: >>> On Tue, Apr 15, 2014 at 06:59:46AM -0700, writeonce@midipix.org wrote: >>>> Greetings, >>>> I could not find in the archives any discussion of the above topic, and >>>> was therefore wondering: would it be possible to have fopen64 and friends >>>> (fseeko64, ftello64, tmpfile64) as aliases of the non-prefixed functions, >>>> rather than having them #define'd as synonyms? This will make most of the >>>> musl-llvm patch unnecessary, and could probably help with other packages >>>> as well. >>>> Kind regards, >>>> zg >>> For some of them like stat64, the #define is necessary anyway since >>> there is a struct that also needs to be mapped. So it's not so simple. >>> In any case, the aliases already exist for binary compatibility, but >>> some of them would be masked by these defines even if we declared them >>> in the public headers. >>> >>> Really what you're asking for is just a workaround of a nonsensical >>> bug in llvm, which should just be fixed. There is no excuse for the >>> hack they're doing with namespaces; instead the names should just be >>> properly prefixed to avoid clashing. >> I understand. In that case, and for those functions that do not >> require an extra structure mapping, what is the advantage of >> >> #define fopen64 fopen >> >> over >> >> FILE *fopen64 (const char *__restrict, const char *__restrict); >> >> If the weak alias is already there anyway, then using the latter >> should only "penalize" (by adding a reference to the extra symbol) >> those apps/libs that use fopen64 in the first place. Is that >> correct? > There are three main advantages in my mind: > > 1. Lack of an extra set of prototypes that might need to be correct > and which might not get tested well. > > 2. Avoiding putting references to the nonsense "64" symbols in the > resulting binaries, so that the "64" symbols remain part of the > ABI-compat layer (which could, in theory, be optional at build time > somewhere in the future) rather than part of the public libc API. > > 3. Consistency: due to the need for #define stat64 stat (and perhaps > others like this), using separate prototypes for the "64 functions > would result in inconsistency in the binaries using them; some > symbols would be referenced in the "64" version and others > wouldn't. (And likewise, the "llvm bug" would manifest for some of > them but not others.) > > Rich > > Thanks for the explanation, these are indeed great reasons to stick with #define for all of the "64" functions. As far as llvm goes, and for what it's worth: my own patch of llvm/Target/TargetLibraryInfo.h simply #undefines fopen64, etc., which allows keeping all of the header's original code intact. With llvm-3.4 and using a native musl compiler (gcc-4.8.2), that was the only patch required (tweaking excluded) for the entire thing to compile and build (so no need to further patch TargetLibraryInfo.cpp, etc.) zg