public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* 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).