public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: cygwin@cygwin.com
Subject: Re: long_int vs int byte sizes
Date: Mon, 07 Apr 2014 15:39:00 -0000	[thread overview]
Message-ID: <5342C6B1.2030106@redhat.com> (raw)
In-Reply-To: <20140407144234.GO2061@calimero.vinschen.de>

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

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) <= sizeof (short) <= sizeof (int) <= sizeof (long)
>>
>> Well, there IS the C rule that sizeof(char)==1, and also that char holds
>>> = 8 bits, short holds >= 8 bits, int holds >= 16 bits, long holds >= 32
>> bits.  There is also a POSIX rule that CHAR_BITS==8 (so while C allows a
>> 9-bit or 32-bit char [and yes, such machines exist, although rare],
>> POSIX does not allow that).
> 
> 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)==sizeof(long)==1 for platforms
with 32-bit char.  Again, all that C requires is a <= relationship
between each progressively higher rank type, so the only thing we can't
have is sizeof(short)>sizeof(long).

> 
>> 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.
> 
> 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 :)

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2014-04-07 15:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-06  6:05 Joseph Maxwell
2014-04-06  6:36 ` sisyphus1
2014-04-07  7:49   ` Csaba Raduly
2014-04-07  8:47   ` Corinna Vinschen
2014-04-07 14:16     ` Eric Blake
2014-04-07 14:42       ` Corinna Vinschen
2014-04-07 15:39         ` Eric Blake [this message]
2014-04-07 15:51           ` Corinna Vinschen
2014-04-07 23:41             ` Ross Smith
2014-04-08  8:48               ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5342C6B1.2030106@redhat.com \
    --to=eblake@redhat.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).