[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160126201703.GG238@brightrain.aerifal.cx>
Date: Tue, 26 Jan 2016 15:17:04 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Bits deduplication: current situation
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@...t70.net> wrote:
>
> > * Rich Felker <dalias@...c.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
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.
