From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Bits deduplication: current situation
Date: Tue, 26 Jan 2016 15:17:04 -0500 [thread overview]
Message-ID: <20160126201703.GG238@brightrain.aerifal.cx> (raw)
In-Reply-To: <CACcSVPG_hmeAJnbuQPe1HatKS4tiezqugabXhWfUk-g7One=Ow@mail.gmail.com>
On Mon, Jan 25, 2016 at 09:03:54PM -0800, Dan Gohman wrote:
> On Mon, Jan 25, 2016 at 1:32 PM, Szabolcs Nagy <nsz@port70.net> wrote:
>
> > * Rich Felker <dalias@libc.org> [2016-01-25 16:00:05 -0500]:
> > > On Mon, Jan 25, 2016 at 11:22:13AM -0800, Dan Gohman wrote:
> > > > Concerning stdint.h, there are a few details beyond just 32-bit vs
> > 64-bit.
> > > > For example, int64_t can be either "long" or "long long" on an LP64
> > target.
> > > > The difference usually doesn't matter, but there are things which end
> > up
> > > > noticing, like C++ name mangling and C format-string checking.
> > >
> > > I'm pretty sure int64_t is long on all LP64 targets we support. Are
> > > there others that differ?
>
> I'm working on an architecture which does, though there's no musl support
> for it currently.
Is this for Linux to run on, or for non-Linux use? I'm pretty sure GCC
wants the above policy for LP64 to be followed on all Linux targets,
and generally considers this part of the general ABI descended from
sysv. Doing it differently is surely a gratuitous incompatibility and
pain for implementations.
Rich
prev parent reply other threads:[~2016-01-26 20:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 3:59 Rich Felker
2016-01-25 8:08 ` Natanael Copa
2016-01-25 17:17 ` Rich Felker
2016-01-25 10:46 ` Laurent Bercot
2016-01-25 14:56 ` Ward Willats
2016-01-25 15:37 ` Szabolcs Nagy
2016-01-25 19:22 ` Dan Gohman
2016-01-25 21:00 ` Rich Felker
2016-01-25 21:32 ` Szabolcs Nagy
2016-01-26 5:03 ` Dan Gohman
2016-01-26 10:18 ` Szabolcs Nagy
2016-01-26 15:16 ` Dan Gohman
2016-01-26 20:26 ` Szabolcs Nagy
2016-01-26 20:17 ` Rich Felker [this message]
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=20160126201703.GG238@brightrain.aerifal.cx \
--to=dalias@libc.org \
--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).