* long_int vs int byte sizes @ 2014-04-06 6:05 Joseph Maxwell 2014-04-06 6:36 ` sisyphus1 0 siblings, 1 reply; 10+ messages in thread From: Joseph Maxwell @ 2014-04-06 6:05 UTC (permalink / raw) To: cygwin Not sure if this is hardware, software or compiler dependent $ uname -a CYGWIN_NT-5.1 machinename 1.7.28(0.271/5/3) 2014-02-09 21:06 i686 Cygwin On a 32 bit XP SP 3 platform wrote a small profram to check some parameters; Received the following Re: Signed abd unsigned iintegers [quote] int x = 0xAB78 in decimal format is : 43896 and unsigned int y = 0xAB78 in decimal format is : 43896 The size of int is 4 bytes [/quote] Not quite what I expected, sine the leftmost bit in 'int' is 1 and would be the negative flag. So wrote another for byte sizes and got the following - [quote] The size of short int is 2 bytes The size of int is 4 bytes The size of long int is 4 bytes The size of double is 8 bytes The size of long double is 12 bytes [/quote] Note size of int and long int are the same both are 4 bytes long Is this to be expected? Thanks! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: long_int vs int byte sizes 2014-04-06 6:05 long_int vs int byte sizes Joseph Maxwell @ 2014-04-06 6:36 ` sisyphus1 2014-04-07 7:49 ` Csaba Raduly 2014-04-07 8:47 ` Corinna Vinschen 0 siblings, 2 replies; 10+ messages in thread From: sisyphus1 @ 2014-04-06 6:36 UTC (permalink / raw) To: Joseph Maxwell, cygwin -----Original Message----- From: Joseph Maxwell > [quote] > int x = 0xAB78 in decimal format is : 43896 > and > unsigned int y = 0xAB78 in decimal format is : 43896 > The size of int is 4 bytes > [/quote] > > Not quite what I expected, sine the leftmost bit in 'int' is 1 and > would be the negative flag. No - the full 32-bit representation of 0xAB78 is: 0000 0000 0000 0000 1010 1011 0111 1000 The leftmost bit is zero. > Note size of int and long int are the same both are 4 bytes long > > Is this to be expected? I think so. I've not yet struck a case on Windows where either int or long are not 4 bytes. (Haven't tried Cygwin64.) Certainly, on some other systems, int is 4 bytes and long is 8 bytes. The standards permit both configurations. Cheers, Rob -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: long_int vs int byte sizes 2014-04-06 6:36 ` sisyphus1 @ 2014-04-07 7:49 ` Csaba Raduly 2014-04-07 8:47 ` Corinna Vinschen 1 sibling, 0 replies; 10+ messages in thread From: Csaba Raduly @ 2014-04-07 7:49 UTC (permalink / raw) To: cygwin list; +Cc: Joseph Maxwell On Sun, Apr 6, 2014 at 8:35 AM, Rob wrote: > I think so. I've not yet struck a case on Windows where either int or long > are not 4 bytes. (Haven't tried Cygwin64.) Obviously you never used a 16-bit compiler :) (where int is 16 bits and long is 32 bits usually) Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: long_int vs int byte sizes 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 1 sibling, 1 reply; 10+ messages in thread From: Corinna Vinschen @ 2014-04-07 8:47 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1334 bytes --] On Apr 6 16:35, sisyphus1@optusnet.com.au wrote: > -----Original Message----- From: Joseph Maxwell > > >[quote] > >int x = 0xAB78 in decimal format is : 43896 > >and > >unsigned int y = 0xAB78 in decimal format is : 43896 > >The size of int is 4 bytes > >[/quote] > > > >Not quite what I expected, sine the leftmost bit in 'int' is 1 and > >would be the negative flag. > > No - the full 32-bit representation of 0xAB78 is: > > 0000 0000 0000 0000 1010 1011 0111 1000 > > The leftmost bit is zero. > > > >Note size of int and long int are the same both are 4 bytes long > > > >Is this to be expected? > > I think so. I've not yet struck a case on Windows where either int > or long are not 4 bytes. (Haven't tried Cygwin64.) On x86_64 Cygwin, sizeof (long) == 8. See http://cygwin.com/faq/faq.html#faq.programming.64bitporting > Certainly, on some other systems, int is 4 bytes and long is 8 bytes. > The standards permit both configurations. 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) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: long_int vs int byte sizes 2014-04-07 8:47 ` Corinna Vinschen @ 2014-04-07 14:16 ` Eric Blake 2014-04-07 14:42 ` Corinna Vinschen 0 siblings, 1 reply; 10+ messages in thread From: Eric Blake @ 2014-04-07 14:16 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 952 bytes --] 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). 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. -- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: long_int vs int byte sizes 2014-04-07 14:16 ` Eric Blake @ 2014-04-07 14:42 ` Corinna Vinschen 2014-04-07 15:39 ` Eric Blake 0 siblings, 1 reply; 10+ messages in thread From: Corinna Vinschen @ 2014-04-07 14:42 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1441 bytes --] 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? 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. > 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? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: long_int vs int byte sizes 2014-04-07 14:42 ` Corinna Vinschen @ 2014-04-07 15:39 ` Eric Blake 2014-04-07 15:51 ` Corinna Vinschen 0 siblings, 1 reply; 10+ messages in thread From: Eric Blake @ 2014-04-07 15:39 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: long_int vs int byte sizes 2014-04-07 15:39 ` Eric Blake @ 2014-04-07 15:51 ` Corinna Vinschen 2014-04-07 23:41 ` Ross Smith 0 siblings, 1 reply; 10+ messages in thread From: Corinna Vinschen @ 2014-04-07 15:51 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1638 bytes --] On Apr 7 09:39, Eric Blake wrote: > 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. C99 actually requires that? Wow. Modern times... > > 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 :) Probably not, but I don't know a Cygwin application to control a washing machine either :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: long_int vs int byte sizes 2014-04-07 15:51 ` Corinna Vinschen @ 2014-04-07 23:41 ` Ross Smith 2014-04-08 8:48 ` Corinna Vinschen 0 siblings, 1 reply; 10+ messages in thread From: Ross Smith @ 2014-04-07 23:41 UTC (permalink / raw) To: cygwin On 2014-04-08 03:51, Corinna Vinschen wrote: > On Apr 7 09:39, Eric Blake wrote: >> >> 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. > > C99 actually requires that? Wow. Modern times... It was already required in C89; the only change in C99 was the addition of long long. Ross Smith -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: long_int vs int byte sizes 2014-04-07 23:41 ` Ross Smith @ 2014-04-08 8:48 ` Corinna Vinschen 0 siblings, 0 replies; 10+ messages in thread From: Corinna Vinschen @ 2014-04-08 8:48 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 864 bytes --] On Apr 8 11:41, Ross Smith wrote: > On 2014-04-08 03:51, Corinna Vinschen wrote: > >On Apr 7 09:39, Eric Blake wrote: > >> > >>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. > > > >C99 actually requires that? Wow. Modern times... > > It was already required in C89; the only change in C99 was the > addition of long long. C89 actually requires that? Wow. Modern times... ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-04-08 8:48 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-06 6:05 long_int vs int byte sizes 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 2014-04-07 15:51 ` Corinna Vinschen 2014-04-07 23:41 ` Ross Smith 2014-04-08 8:48 ` Corinna Vinschen
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).