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
signature.asc
Description: OpenPGP digital signature