From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: fopen64 and friends as aliases
Date: Tue, 15 Apr 2014 15:15:35 -0400 [thread overview]
Message-ID: <20140415191535.GB26358@brightrain.aerifal.cx> (raw)
In-Reply-To: <534D829A.8030808@midipix.org>
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
next prev parent reply other threads:[~2014-04-15 19:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 13:59 writeonce
2014-04-15 14:21 ` Rich Felker
2014-04-15 19:03 ` writeonce
2014-04-15 19:15 ` Rich Felker [this message]
2014-04-15 19:38 ` writeonce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140415191535.GB26358@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).