Date: Tue, 26 Jan 2016 07:16:08 -0800 From: Dan Gohman <sunfish@...illa.com> To: musl@...ts.openwall.com Subject: Re: Bits deduplication: current situation On Tue, Jan 26, 2016 at 2:18 AM, Szabolcs Nagy <nsz@...t70.net> wrote: > * Dan Gohman <sunfish@...illa.com> [2016-01-25 21:03:54 -0800]: > > 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]: > > > > > > > > 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. > > > > in gcc stdint.h only depends on libc/os and sizeof(long), > not on architecture. > > (e.g. openbsd uses long long, glibc uses long consistently > for all LP64 arch abis.) > I've been assuming that, in the absence of compatibility constraints (for example on a new architecture), it would be reasonable for hypothetical new musl, glibc, or newlib ports to arrange to be ABI compatible at the level of a freestanding implementation (in the C standard sense), which would include <stdint.h>. Is this an incorrect assumption, from your perspective? Dan Content of type "text/html" skipped
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.