Date: Tue, 26 Jan 2016 21:26:00 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: Bits deduplication: current situation * Dan Gohman <sunfish@...illa.com> [2016-01-26 07:16:08 -0800]: > 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? it is correct in principle, but it means a bit more toolchain work to support an inconsistent arch and it can bite you if you work with historical code with invalid assumptions. gcc/musl/glibc/linux all use consistent typedefs for all 64bit archs, most likely other projects do the same. in most cases it should be easy to do the typedefs differently for a new arch, but there might be caveats.. i think if you want to design a freestanding c language abi for your arch then it makes sense to follow what's already there (unless you have some specific reason to deviate).
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.