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=V06Cv+
	wV/1fPUtKP7ClvPcEBGHNng3H+GmXXDO0Kp/nWZ37JG2RLlpe3liS4bY5IbgiuxN
	S73a0IakKJyTU4NfHS9q5i4AoOrc3lshxeOrvQiZGLiU4JYSwkJa+8cN1ifh/r0R
	vQL5LHZcy7W0HBUn4kJqbp+DHVp40KE91+nQQ=
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=dbgFNCjxIjvv
	vXBXHrqp7WgjR9k=; b=ds9j8McewgsAB8lYAUmdBAHHGCtxOsGyfAahKokNzRRy
	jVvhIPtSnvCGbicyuJbIwxD6NGYwnb9f9qmL7mqslDMF61gKlFzNi7/2Gn0WfJtq
	R3t0f/U8gCG0ylHWuLJvJHl6Ycl/vAl8Qh1zNMKV4IpDiby150bRauPB2GDIKxg=
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=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mx1.redhat.com
Message-ID: <5342C6B1.2030106@redhat.com>
Date: Mon, 07 Apr 2014 09:39:29 -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> <5342B32D DOT 80508 AT redhat DOT com> <20140407144234 DOT GO2061 AT calimero DOT vinschen DOT de>
In-Reply-To: <20140407144234.GO2061@calimero.vinschen.de>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nfN0X28mK5TQK09kwpjIetxqVXJB4j5NA"
X-IsSubscribed: yes

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

On 04/07/2014 08:42 AM, Corinna Vinschen wrote:
> On Apr  7 08:16, Eric Blake wrote:
>> On 04/07/2014 02:47 AM, Corinna Vinschen wrote:
>>
>>>
>>> There's no standard which restricts the sizes of the datatypes in
>>> that way.  There's only this rule to follow:
>>>
>>>   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 h=
olds
>>> =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 allo=
ws a
>> 9-bit or 32-bit char [and yes, such machines exist, although rare],
>> POSIX does not allow that).
>=20
> Apart from POSIX, where is that defined?

C99 5.2.4.2.1 Sizes of integer types <limits.h>

requires CHAR_BIT to be 8 or larger, UCHAR_MAX to be 255 or larger,
USHRT_MAX to be 65535 or larger (oh, so I was wrong above; 8-bit short
is not allowed), UINT_MAX to be 65535 or larger, ULONG_MAX to be
4294967295 or larger, and ULLONG_MAX to be 18446744073709551615 or larger.

POSIX then requires CHAR_BIT to be exactly 8.

>  The old K&R rules only defined
> the sizes of the datatypes in comparison to each other, but it never
> defined minimum sizes.  If you have a 7 bit machine and you only use
> ASCII, you can be happy ever after.  And while it *suggested* that short
> < long, it didn't demand it.

K&R C probably did allow for 7-bit char.  I'm not sure off-hand what C89
required, but C99 definitely prohibits a 7-bit char type.  However, you
ARE correct that C99 allows sizeof(short)=3D=3Dsizeof(long)=3D=3D1 for plat=
forms
with 32-bit char.  Again, all that C requires is a <=3D relationship
between each progressively higher rank type, so the only thing we can't
have is sizeof(short)>sizeof(long).

>=20
>> 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
> Xstormy16?

Okay, so maybe 16-bit machines aren't all museum pieces - but they also
aren't portability targets for the majority of programs run on cygwin :)

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


--nfN0X28mK5TQK09kwpjIetxqVXJB4j5NA
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/

iQEcBAEBCAAGBQJTQsaxAAoJEKeha0olJ0NqE28IAJSFdWHyD7NroGHHtNoowKxE
F0RwWyf93egqbrfQc77YEizBL1Oj6iGUu8k/JgO2HXtNgmwN2iwx2HAdKZ2MiUtQ
0/2MGbbl2+cdUln9EmSon7lG52JwLQpAbc9yeIUUpBnGHrcio3zuJzMpvbT9oQTe
6hU1IC9LHqxX/hfth56evkYCQAWHZfS4tYc9MBULNvL8qnlqTYtnIZ2sKU9DJPKR
W0rSDs8rQ6WOv+Rvl5XluXWAadcEoGfQl17fxjhCFukthzWY00CEnp6aafMJ7ea9
Rtn9woSi6K5d1kTqihFxjbg6MZLXb+EL5idRzmOBL6h8XZFqseSiinT2OVNZ/GQ=
=QwkN
-----END PGP SIGNATURE-----

--nfN0X28mK5TQK09kwpjIetxqVXJB4j5NA--