From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9149 Path: news.gmane.org!not-for-mail From: Max Ruttenberg Newsgroups: gmane.linux.lib.musl.general Subject: Re: the size of the int type Date: Mon, 18 Jan 2016 10:22:15 -0500 Message-ID: References: <20160116110916.GA20353@openwall.com> <1452949769.30789.1.camel@inria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c17f545dad3705299d5122 X-Trace: ger.gmane.org 1453130558 17121 80.91.229.3 (18 Jan 2016 15:22:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 15:22:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9162-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 18 16:22:33 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 1aLBdX-00076L-6D for gllmg-musl@m.gmane.org; Mon, 18 Jan 2016 16:22:31 +0100 Original-Received: (qmail 24046 invoked by uid 550); 18 Jan 2016 15:22:28 -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 24022 invoked from network); 18 Jan 2016 15:22:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emutechnology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cxtTXCnXCO19E8WRUrb6NvsPTIkSo8U9IMQUKp7SjwA=; b=J+Yxhwcmucr3a+mDsMJeuKx6WktrwalIRdjAJWnvxNdr3zATXamtnAXAJ2Qx+8unXP YVEZAraCiLN//mtlX1LCKC7+i5i0DKUNALV58KOfNJo9VyBZY33F3O1Gq8IX+0GbmMpy mHcYPY9PHdcvaeyHhJ4/LXy8+SMeprOvCG+0ZWCC07baVxNjdUqAtKS0knUY1tHrkktH fMfIMTIZuPqNfRk+aJMCLEdT0+nbyjbRyJLNl0AHhKBt65ZH0DFfXAjzsm6neyMcYusq SQ+bYhe4z0jtzlBr5x0WXtaBtSIoKhhE2IFkffJ+nLGLN16Re52ezrGBNA4BydlbkI2g QinQ== 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:content-type; bh=cxtTXCnXCO19E8WRUrb6NvsPTIkSo8U9IMQUKp7SjwA=; b=Uu3IxUEFazdid+OiAei9Ibb5xbjaYWFARn1Mc9ScFbS8xqekSaY3KqEdCcfgRwkPMk hV0aAQc2Hw5qiCnngyZPghxbkl/1mgDAH5CVdlkhA8ZzLGtIwZZifMRygvhcOzqFtP8j axd6dLUHipHx/6UTRoGu2eBsRzwkyHinxjD9VP/PDbPKB0Xyo4gLoYb/phrk+HJW34Ol NFztsr8xqnUnBI65B6Gbxt9myclIeP/ND+/yryBqGG3V2/31S414LKhzBYn+r+FK3Oxg YSPVWREaJvTGlQTTL2UBngxA2HfmPEmrs+J1Wn3Kykxq02JhG0wmLGQkqO669mczPvBt yyvw== X-Gm-Message-State: ALoCoQmpyb0gjCZj0qWzYyFv7QiqH+dW1ihONit9Ycfx4u0Lb0X8J5frodzxp/QCC/PL/KFwqJM2JNSU703a6RqvFQc61k/6MA== X-Received: by 10.202.75.15 with SMTP id y15mr16956639oia.16.1453130535235; Mon, 18 Jan 2016 07:22:15 -0800 (PST) In-Reply-To: <1452949769.30789.1.camel@inria.fr> Xref: news.gmane.org gmane.linux.lib.musl.general:9149 Archived-At: --001a11c17f545dad3705299d5122 Content-Type: text/plain; charset=UTF-8 All, Thank you! You have convinced me that I should leave int as 32-bit, long long as 64-bit, and long as the word size of the machine. On Sat, Jan 16, 2016 at 8:09 AM, Jens Gustedt wrote: > Am Samstag, den 16.01.2016, 14:09 +0300 schrieb croco@openwall.com: > > On Fri, Jan 15, 2016 at 09:11:25PM +0000, Josiah Worcester wrote: > > > > > You would do better to match the convention used on modern-day Unix > > > systems, where int is 32-bit, long is the machine word size, and long > long > > > is 64-bit. If you do this everything should pretty much function as it > > > expects, with regard to the standard C types' sizes. > > > > Let me second this. Please note that in case you implement int as > 64-bit, > > then there will be either no 32-bit or no 16-bit integer type (at all), > as > > there's only the short which is in between char ant int; hence, well, > there > > will be a kind of problem with some typedefs from : either > > int16_t/uint16_t or int32_t/uint32_t will actually have a size different > > from what the name suggests, so you'll run into a trouble with > > reading/analysing data in binary formats. > > You certainly shouldn't do it like that. If you can't support > [u]intXX_t for some XX, you shouldn't define these types. These are > optional types in the C standard, but if they are defined they must > have the exact width, and the intXX_t must have two's complement > representation. > > Mandatory are only the [u]int_leastXX_t types for XX = 8, 16, 32 and > 64. But as the name indicates, these don't have to have the exact > width. > > In any case you should just stick to the standard ABI of your > platform. Everything else would be opening a can of worms. > > Jens > > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: ::::::::::::::: office Strasbourg : +33 368854536 :: > :: :::::::::::::::::::::: gsm France : +33 651400183 :: > :: ::::::::::::::: gsm international : +49 15737185122 :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > > > > -- Max Ruttenberg, Member of the Technical Staff Emu *Technology* 1400 E Angela Blvd, Unit 101 South Bend, IN 46617 --001a11c17f545dad3705299d5122 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Thank you! You have convinced me t= hat I should leave int as 32-bit, long long as 64-bit, and long as the word= size of the machine.

On Sat, Jan 16, 2016 at 8:09 AM, Jens Gustedt <jens.g= ustedt@inria.fr> wrote:
Am Samstag, den 16.01.2016, 14:09 +0300 schrieb croco@openwall.com:
> On Fri, Jan 15, 2016 at 09:11:25PM +0000, Josiah Worcester wrote:
>
> > You would do better to match the convention used on modern-day Un= ix
> > systems, where int is 32-bit, long is the machine word size, and = long long
> > is 64-bit. If you do this everything should pretty much function = as it
> > expects, with regard to the standard C types' sizes.
>
> Let me second this.=C2=A0 Please note that in case you implement int a= s 64-bit,
> then there will be either no 32-bit or no 16-bit integer type (at all)= , as
> there's only the short which is in between char ant int; hence, we= ll, there
> will be a kind of problem with some typedefs from <stdint.h>: ei= ther
> int16_t/uint16_t or int32_t/uint32_t will actually have a size differe= nt
> from what the name suggests, so you'll run into a trouble with
> reading/analysing data in binary formats.

You certainly shouldn't do it like that. If you can't suppor= t
[u]intXX_t for some XX, you shouldn't define these types. These are
optional types in the C standard, but if they are defined they must
have the exact width, and the intXX_t must have two's complement
representation.

Mandatory are only the [u]int_leastXX_t types for XX =3D 8, 16, 32 and
64. But as the name indicates, these don't have to have the exact
width.

In any case you should just stick to the standard ABI of your
platform. Everything else would be opening a can of worms.

Jens


--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536=C2=A0 =C2=A0::
:: :::::::::::::::::::::: gsm France : +33 651400183=C2=A0 =C2=A0::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gu= stedt ::






--
Max Rutten= berg,
Member of the Technical Staff
Emu=C2=A0Technology
1400 E Angela Blvd, Unit 101
South Bend, IN 46617
=
--001a11c17f545dad3705299d5122--