From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9799 Path: news.gmane.org!not-for-mail From: Dan Gohman Newsgroups: gmane.linux.lib.musl.general Subject: size_t and int64_t on a new platform Date: Thu, 31 Mar 2016 11:20:22 -0700 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114e4716c75804052f5c50bc X-Trace: ger.gmane.org 1459448453 25052 80.91.229.3 (31 Mar 2016 18:20:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Mar 2016 18:20:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9812-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 31 20:20:43 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 1alhD1-0008Sd-5p for gllmg-musl@m.gmane.org; Thu, 31 Mar 2016 20:20:43 +0200 Original-Received: (qmail 20441 invoked by uid 550); 31 Mar 2016 18:20:41 -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 20391 invoked from network); 31 Mar 2016 18:20:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=Q5wl/wLtwNR+98aRJU8bvEzDcjNQ3alsptVvUfCuBfI=; b=qbpgyQMWoQoMMt3UEGqyIJkCbWNZ4hCQ6eYY+tiJxFOB+U14m2+BcCB9QUEnw1sWq9 20JMxe+0mOjSJ45KyP9PS8AJE0KWfkt6ORWq1SH61pfnqvGVQ1CrVadUCeoTA2QlNDw/ 3hFMKTHpEFomGBiri3vD4KjKgRAtI0oyJOHTmV+BDN+ZmYOcJURSGob5ggbzj8eeWIzO VKIHNq6TOhHi1zqhdiNLcbxESKozoXD/UfAruyv39H0aJmtSfajXArpnKgUNCxGzlwCH y3CktqgdxMmWwArnSnVHofd9rIvUxTDAfWPBAFTeqrFfrH4/B3wAM+gGa06hsj2P9r3i dawg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=Q5wl/wLtwNR+98aRJU8bvEzDcjNQ3alsptVvUfCuBfI=; b=Xp9Zv0K2xb1uRi61R/CIHPgIGSSV3CEzbdtgPcNO+3f0jfbnseodLom6OYTTHQEad+ oksCnVZ0gMp8N/rddXss1Yj2EhfrEJqED+Fv16QkiHWScLBx+aNm70ZiKcFKgkWMcl2Q XKrySOe+0G0n0+mFcD0YHyISrN8LuZS5udpLNceTZb6O2zpHncrtKrEKykl0qtRhmx35 U097Zvn+/JRwGW+V+IagRI7dgrWmLCmU+yd40ANNFYMDGBtFDnVSdwoGcmP4o35PxBF0 +dw4mkYkG2O/gGtxz7MAfqeWY67gIjuMzQs2u/yis9ahulesMaTLzYMg7Gqr2VcIK4kU pYTg== X-Gm-Message-State: AD7BkJJd6mrVABtUPVxUqTQa99UAlKnhAugT3pediE+8zTR+PqJjTeh1H77ApIZl0a1kTmDS5U2whphkOzfOLR7e X-Received: by 10.13.201.130 with SMTP id l124mr9188457ywd.212.1459448422267; Thu, 31 Mar 2016 11:20:22 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:9799 Archived-At: --001a114e4716c75804052f5c50bc Content-Type: text/plain; charset=UTF-8 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? Thanks, Dan --001a114e4716c75804052f5c50bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm working on a new architecture (WebAssembly, a= ka wasm) and am hoping to have a compatible ABI at the level of a "fre= estanding implementation" between all libc ports.

Th= e current design would translate into the following in a musl port (in .../= bits/alltypes.h.in):

#define _A= ddr long
#define _Int64 long long

Both the ILP32 and L= P64 platform variants would use the same definitions. This helps minimize d= ifferences between the two variants, which aligns with an overall goal of t= he platform.

However, this differs from musl's convention of usi= ng "int" for _Addr on ILP32 systems and using "long" fo= r _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 portabl= e and can't, or is architecture-specific and can just do the right thin= g for its own architecture.

Legacy code may have assumpti= ons, though I'm aware of the issues and don't believe it's a si= gnificant practical problem for WebAssembly.

If we decide= to contribute wasm support upstream to the musl project in the future, wou= ld the musl maintainers expect to be ok with the above definitions?

Thanks,

Dan

--001a114e4716c75804052f5c50bc--