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