X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type; q=dns; s=default; b=pWUXz0
	u0F8NVnhrQnygKTPZsVcWdCiRTB+wtBUXGCQBI6GlGcRhannUD5QyK433INgyfgb
	iE1THBC4vQ/LkXUWLBwDMAIRjyR0HpDs+K+UZN4Fj3cANv416sLMGOvLH9OHFTMy
	ppilHGHK5ZimB1aWQ3oiGPu1L45uoIe+n6HLw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type; s=default; bh=ZquhKeb8uT5p
	MiLAvRYSfdDmn+0=; b=h/5eFWr31R+GQVuNHVKv5ydB+WtuyDpyUwSgjXvoudEE
	1JSkVLB0p/5Z1UyJsO0OE7KYFd1LNUxvsceS2pQGR/ajMOexgXb7Eof2x5NV00zd
	VUfqkqRS4J0FTOiTjzoKeNCdIpuDAut1EfQ6GAZ1OTub8OrfzI2HMIBvy/ArxOw=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO: qmta04.emeryville.ca.mail.comcast.net
Message-ID: <5342B32D.80508@redhat.com>
Date: Mon, 07 Apr 2014 08:16:13 -0600
From: Eric Blake <eblake AT redhat DOT com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: long_int vs int byte sizes
References: <CABKp57PdLMKqmGFhfMEN4BLPFcndkpibora5yx2Xdy6zh4+WzA AT mail DOT gmail DOT com> <6BA0E670DE2A4416BB5A12250B427E5A AT OwnerPC311012> <20140407084720 DOT GC2061 AT calimero DOT vinschen DOT de>
In-Reply-To: <20140407084720.GC2061@calimero.vinschen.de>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9NuVG4ilChE3TMTb6lnfvvoMDBpKTFcgM"
X-IsSubscribed: yes

--9NuVG4ilChE3TMTb6lnfvvoMDBpKTFcgM
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 04/07/2014 02:47 AM, Corinna Vinschen wrote:

>=20
> There's no standard which restricts the sizes of the datatypes in
> that way.  There's only this rule to follow:
>=20
>   sizeof (char) <=3D sizeof (short) <=3D sizeof (int) <=3D sizeof (long)

Well, there IS the C rule that sizeof(char)=3D=3D1, and also that char holds
>=3D 8 bits, short holds >=3D 8 bits, int holds >=3D 16 bits, long holds >=
=3D 32
bits.  There is also a POSIX rule that CHAR_BITS=3D=3D8 (so while C allows a
9-bit or 32-bit char [and yes, such machines exist, although rare],
POSIX does not allow that).  But in general, on most modern porting
platforms, 'long' is a redundant type - it will either be equal in size
to 'int' (typical for a 32-bit machine) or to a 'long long' (typical for
a 64-bit machine); it only mattered on 16-bit machines which are now
museum pieces.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--9NuVG4ilChE3TMTb6lnfvvoMDBpKTFcgM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJTQrMtAAoJEKeha0olJ0NqhSIH/jznuFPQ6KJ3ziDxYuPb15Uo
Xu6DZli7ku+/6/fO2UyX3Fio+9eBG6CmlpFxURP1r5uX3b48EmnfkWW+h9Jz2tFW
9hzltpON8HWJtPC3uNaUiYtoti3vd5xClEvb/HHch2RcPnJcWGGSANg0BAb0RxLL
9vUhM5Hp1TDrDPYYYiNzdSWRhn66u0c8udcocVpHNRU9fYkvFl7I1PItPuGX5GvR
ee7h4s9YzB2uLVISZKddJkJ7cCKEZdyVapFzGjVWl4UzGp+g3iwCvK0RCMBYhE11
/XLsURumOe4HUbebuazbyecBWme1jC3tAnGbd/QFOUQtx2QAjUhmftbxOvpXqI8=
=GMOb
-----END PGP SIGNATURE-----

--9NuVG4ilChE3TMTb6lnfvvoMDBpKTFcgM--