Date: Tue, 15 Apr 2014 15:38:00 -0400 From: "writeonce@...ipix.org" <writeonce@...ipix.org> To: musl@...ts.openwall.com Subject: Re: fopen64 and friends as aliases On 04/15/2014 03:15 PM, Rich Felker wrote: > On Tue, Apr 15, 2014 at 03:03:54PM -0400, writeonce@...ipix.org wrote: >> On 04/15/2014 10:21 AM, Rich Felker wrote: >>> On Tue, Apr 15, 2014 at 06:59:46AM -0700, writeonce@...ipix.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.