From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9804 Path: news.gmane.org!not-for-mail From: Dan Gohman Newsgroups: gmane.linux.lib.musl.general Subject: Re: size_t and int64_t on a new platform Date: Thu, 31 Mar 2016 17:35:11 -0700 Message-ID: References: <20160331192518.GW21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114907f442150e052f618d52 X-Trace: ger.gmane.org 1459470935 9259 80.91.229.3 (1 Apr 2016 00:35:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2016 00:35:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9817-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 01 02:35:30 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aln3g-0007YX-Uv for gllmg-musl@m.gmane.org; Fri, 01 Apr 2016 02:35:29 +0200 Original-Received: (qmail 7653 invoked by uid 550); 1 Apr 2016 00:35:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7623 invoked from network); 1 Apr 2016 00:35:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=aYo3ICPAOkyxD6OzN28Cp8KyjVGzDo0rLbXGCbb3x24=; b=Y6YHYLXFoMfRt3XWEEgoOF9APzAoOX783G2KSIEMZI9cv4v0HTdurGGritWT8rDTaH uVzbS+daxMZI4OuG3ddWdA2nPTaHNRt/bhDmn2j3xXUnNpGdAw5y0D+8zEAoCbSw1jC7 a7zNsSosjPUJh1LfYMnIk76Ak6qZ10/de550gX6j4uDMw7GqerZyusN15/EPkFbwtd0d dv8mmJhblkxB2ez8dh72DmZitaWk8jJqESVQqBaeYz8NiMIKZGcvj5nki4WxyCqSkdU0 iHAg32hPmqNFbFI3/jBrcu6/ksgv+F101NYubbKwTtMFD4bckQrrJd6t+40PKsK3UpF9 RtFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=aYo3ICPAOkyxD6OzN28Cp8KyjVGzDo0rLbXGCbb3x24=; b=is2+rK7vM107lcdHDabU6GHx4Ia6cHoe9Sj33J3t6I/fzwXEcQjrNnOZOooTXf+CWs fDR0yTrHFBpQaUKRaXEXAxFyYdV7hAxB/wv6nNWEXYLDkvt6m4K9GXAHd2s6nxZf8yXw YBDURr1VT+T7y+giYJFebAKNFCeFVu5h1/naxr17u3wYZg12BVaYzj0YaBVUY8qZQ+BK WoNQ/aMkKgG/OH9+xJ40sWC97G4+R8/Pm/l8CPEF3Dci2s54CS/wDLWu+FbGn5cj9g91 Tm9VVChPJ9HEPPtuK7JpQSGICTI+zExjV0p6iXOOzaW8Rh8yjd4yXmj27pvF2nTa5Gct wWBw== X-Gm-Message-State: AD7BkJJaUYtkoy5AHzqmdQL2vTuTSjWZRg4Q+0CYcr/2HbZtCLzOCn4e9n8zG4el8fX/DlijMkLt1L/Pabkt/QUM X-Received: by 10.129.97.198 with SMTP id v189mr5303114ywb.109.1459470911786; Thu, 31 Mar 2016 17:35:11 -0700 (PDT) In-Reply-To: <20160331192518.GW21636@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9804 Archived-At: --001a114907f442150e052f618d52 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 31, 2016 at 12:25 PM, Rich Felker wrote: > On Thu, Mar 31, 2016 at 11:20:22AM -0700, Dan Gohman wrote: > > I'm working on a new architecture (WebAssembly, aka wasm) and am hoping > to > > have a compatible ABI at the level of a "freestanding implementation" > > between all libc ports. > > > > The current design would translate into the following in a musl port (in > > ..../bits/alltypes.h.in): > > > > #define _Addr long > > #define _Int64 long long > > > > Both the ILP32 and LP64 platform variants would use the same definitions. > > This helps minimize differences between the two variants, which aligns > with > > an overall goal of the platform. > > > > However, this differs from musl's convention of using "int" for _Addr on > > ILP32 systems and using "long" for _Int64 on LP64 systems. But, as far > as I > > can tell, no musl code actually depends on this convention. Almost all > code > > in musl is either fully portable and can't, or is architecture-specific > and > > can just do the right thing for its own architecture. > > > > Legacy code may have assumptions, though I'm aware of the issues and > don't > > believe it's a significant practical problem for WebAssembly. > > > > If we decide to contribute wasm support upstream to the musl project in > the > > future, would the musl maintainers expect to be ok with the above > > definitions? > > At some point we'll probably have to make this relaxation anyway. I've > heard there's at least one arch we're planning to add (maybe > powerpc64? I forget) that's using long instead of int for _Addr types. > What would be most helpful to us (to keep things simple) is just > ensuring that all the relevant types (size_t, ssize_t, ptrdiff_t, > [u]intptr_t, etc.) are defined consistently as int or as long; > otherwise we have to pop a hole in the abstraction they're modeled > with now. That wouldn't be a huge problem either but it just adds more > redundancy to arch/*/bits/alltypes.h.in files. > Sounds good. And I agree; size_t, ssize_t, ptrdiff_t, [u]intptr_t, etc. would all remain consistent with each other. And to answer the concerns about compilers, I'm also a developer on the first C/C++ compiler being ported to this platform, so I'll make sure that the compiler's types agree with those defined in the library headers. Thanks, Dan --001a114907f442150e052f618d52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 31, 2016 at 12:25 PM, Rich Felker <dalias@libc.org> wrote:
On Thu, Mar 31, 2016 a= t 11:20:22AM -0700, Dan Gohman wrote:
> I'm working on a new architecture (WebAssembly, aka wasm) and am h= oping to
> have a compatible ABI at the level of a "freestanding implementat= ion"
> between all libc ports.
>
> The current design would translate into the following in a musl port (= in
> ..../bits/alltypes.h.in):
>
> #define _Addr long
> #define _Int64 long long
>
> Both the ILP32 and LP64 platform variants would use the same definitio= ns.
> This helps minimize differences between the two variants, which aligns= with
> an overall goal of the platform.
>
> However, this differs from musl's convention of using "int&qu= ot; for _Addr on
> ILP32 systems and using "long" for _Int64 on LP64 systems. B= ut, as far as I
> can tell, no musl code actually depends on this convention. Almost all= code
> in musl is either fully portable and can't, or is architecture-spe= cific and
> can just do the right thing for its own architecture.
>
> Legacy code may have assumptions, though I'm aware of the issues a= nd don't
> believe it's a significant practical problem for WebAssembly.
>
> If we decide to contribute wasm support upstream to the musl project i= n the
> future, would the musl maintainers expect to be ok with the above
> definitions?

At some point we'll probably have to make this relaxation anyway= . I've
heard there's at least one arch we're planning to add (maybe
powerpc64? I forget) that's using long instead of int for _Addr types.<= br> What would be most helpful to us (to keep things simple) is just
ensuring that all the relevant types (size_t, ssize_t, ptrdiff_t,
[u]intptr_t, etc.) are defined consistently as int or as long;
otherwise we have to pop a hole in the abstraction they're modeled
with now. That wouldn't be a huge problem either but it just adds more<= br> redundancy to arch/*/bits/alltypes.h.in files.

Sounds good. And I agree; size_t, ssize_t, ptrdiff_t, [u]intptr_t, e= tc. would all remain consistent with each other.

And to a= nswer the concerns about compilers, I'm also a developer on the first C= /C++ compiler being ported to this platform, so I'll make sure that the= compiler's types agree with those defined in the library headers.
<= br>
Thanks,

Dan

<= br>
--001a114907f442150e052f618d52--