Hi All,

As we all know, in C, the size of int depends on underlying platform,
and typically is of 2 bytes or 4 bytes. Whereas the size of long
dattype is atleast of 4 bytes. I think these things are tru only for 16
and 32 bit OS, what about 64 bit OS?? Obviously the int size will be of
64 bit, but what will be of long size??

Actually I came accross a issue, as in some protocols, some fields are
of 4 bytes. So for that I used to take unsigned long data type, to read
and write those 4 bytes. Now what datatype we can use for that in a 64
bit OS??(if we don't want to use our own procedures for reading/writing
those 4 bytes in integers).

In comp.unix.programmer myself_rajat@yahoo.com wrote:
: Hi All,

: As we all know, in C, the size of int depends on underlying platform,
: and typically is of 2 bytes or 4 bytes. Whereas the size of long
: dattype is atleast of 4 bytes. I think these things are tru only for 16
: and 32 bit OS, what about 64 bit OS?? Obviously the int size will be of
: 64 bit, but what will be of long size??

Typically, not. 

I've collected expermimental data of sizeof for variuous types on
various platforms on the  http://www.45.free.net/~vitus/intsize.html
There are four 64-bit platforms in the table:
FreeBSD on AMD/Opteron, Solaris on Sparc64, HP/UX on Itanium 64 and
HP/UX on PA-RISC 64.

On all these platforms size of POINTER is 64 bit, and Long is 64 bit
also. But int is still 32 bit for compatibility with most applications.

As far as I know, 64-bit Windows (on AMD, Intel E64T, Itanium) goes even
further - they keep long 32bit and only long long (or int64_t) and
pointers are 64 bit. Although I've done no experiments.

BTW, if somebody have a platform or compiler,
which is not listed in this table, fill
free to run supplied program and send me a results.




-- 

On 20 May 2005 03:40:35 -0700, myself_rajat@yahoo.com <myself_rajat@yahoo.com>
 wrote:
> As we all know, in C, the size of int depends on underlying platform,
> and typically is of 2 bytes or 4 bytes. Whereas the size of long
> dattype is atleast of 4 bytes. I think these things are tru only for 16
> and 32 bit OS, what about 64 bit OS?? Obviously the int size will be of
> 64 bit, but what will be of long size??

Actually, it's somewhat typical that int is 32 bits and long 64 bits
on 64-bit platforms, but as you yourself said, that's platform spesific
and doesn't really depend on the bitness of the OS. (Some platforms
eg. have 32-bit ints and longs even in 64-bit mode and just have
long longs be 64-bit.)

Anyway, if you want types with spesific or guaranteed minimum sizes,
use stdint.h�. If some platform doesn't support it, add the needed
definitions for that spesific platform yourself.

(I think comp.unix.programmer is more appropriate, hence followups set.)

� <URL: http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html >

-- 
Mikko Rauhala   - mjr@iki.fi     - <URL:http://www.iki.fi/mjr/>
Transhumanist   - WTA member     - <URL:http://www.transhumanism.org/>
Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>

Hello,

> Actually, it's somewhat typical that int is 32 bits and long 64 bits
> on 64-bit platforms, but as you yourself said, that's platform
spesific
> and doesn't really depend on the bitness of the OS. (Some platforms
> eg. have 32-bit ints and longs even in 64-bit mode and just have
> long longs be 64-bit.)

Some platforms (Cray...) have even 64-bit ints.


> Anyway, if you want types with spesific or guaranteed minimum sizes,
> use stdint.h=B9. If some platform doesn't support it, add the needed
> definitions for that spesific platform yourself.

Excellent advice.=20

Loic.

vitus@45.free.net (Victor Wagner) writes:

> In comp.unix.programmer myself_rajat@yahoo.com wrote:
> : Hi All,
>
> : As we all know, in C, the size of int depends on underlying platform,
> : and typically is of 2 bytes or 4 bytes. Whereas the size of long
> : dattype is atleast of 4 bytes. I think these things are tru only for 16
> : and 32 bit OS, what about 64 bit OS?? Obviously the int size will be of
> : 64 bit, but what will be of long size??
>
> Typically, not. 
>
> I've collected expermimental data of sizeof for variuous types on
> various platforms on the  http://www.45.free.net/~vitus/intsize.html
> There are four 64-bit platforms in the table:
> FreeBSD on AMD/Opteron, Solaris on Sparc64, HP/UX on Itanium 64 and
> HP/UX on PA-RISC 64.
>
> On all these platforms size of POINTER is 64 bit, and Long is 64 bit
> also. But int is still 32 bit for compatibility with most applications.
>
> As far as I know, 64-bit Windows (on AMD, Intel E64T, Itanium) goes even
> further - they keep long 32bit and only long long (or int64_t) and
> pointers are 64 bit. Although I've done no experiments.

Some 64-bit operating systems can run programs with a 32-bit
personality, meaning that only 32-bit addresses will be used.  This is
to make porting of badly written programs assuming 32-bit pointers
easier.  Of course it requires compiler support as well.  I read
somewhere that this is what they had to do to make netscape run on
tru64.

> BTW, if somebody have a platform or compiler,
> which is not listed in this table, fill
> free to run supplied program and send me a results.

Linux on Alpha, GCC and CCC compilers (gcc 3.3.3, ccc 6.5.6, all
versions should be the same):

short=2
int=4
long=8
long long=8
size_t=8
int *=8
time_t=8
wchar_t=4
float=4
double=8
long double=8

-- 
M�ns Rullg�rd
mru@inprovide.com

myself_rajat@yahoo.com wrote:
> Hi All,
> 
> As we all know, in C, the size of int depends on underlying platform,
> and typically is of 2 bytes or 4 bytes. Whereas the size of long
> dattype is atleast of 4 bytes. I think these things are tru only for 16
> and 32 bit OS, what about 64 bit OS?? Obviously the int size will be of
> 64 bit, but what will be of long size??
> 
> Actually I came accross a issue, as in some protocols, some fields are
> of 4 bytes. So for that I used to take unsigned long data type, to read
> and write those 4 bytes. Now what datatype we can use for that in a 64
> bit OS??(if we don't want to use our own procedures for reading/writing
> those 4 bytes in integers).
Find something that's atleast big as 32 bits. Check your 
compiler/platform docs.

For simplicity, lets say a long is 64 bits, and a unsigned char is 8 
bits on your platform.
You can write it like 4 bytes by simply,
void pickleulong32(unsigned long v, unsigned char *res)
{
	res[0] = (0xff000000&v)>> 24;
	res[1] = (0x00ff0000&v)>> 16;
	res[2] = (0x0000ff00&v >>  8;
	res[4] = (0x0000000ff&v);
}
Flip it around according to what endian you need in the output.

(don't go around imagine your struct tcp {..} or whatever, needs to 
match exactly what goes on the wire. Marshall it with routines like the 
above.)

If your're lucky enough, you have stdint.h, include that and use
uint32_t instead of unsigned long, and uint8_t instead of unsigned char.

In comp.unix.programmer M?ns Rullg?rd <mru@inprovide.com>
wrote:
: Some 64-bit operating systems can run programs with a 32-bit
: personality, meaning that only 32-bit addresses will be used.  This is
: to make porting of badly written programs assuming 32-bit pointers

Not only. Typically, on most modern architectures most utilities run a
bit faster an consume less memory if compiled 32-bit. Difference is
negligible, but my test Solaris system have entire userland 32-bit but
is able to run 64 bit programs. Ditto for both HP/UX systems listed in
my table.

So I've collected data for 32-bit and 64-bit programs on same host, just
using -m32 and -m64 switches for GCC (and appropriate switches for HP/UX
compiler) when compiling my test program.

Only system in my list which was unable to run 32-bit programs was
FreeBSD/Opteron. And this possibly bug in the setup of particular
FreeBSD machine (which is not mine, although I have login on it), rather
than deficiency of OS.

-- 

On Fri, 20 May 2005 12:56:48 +0000 (UTC), Victor Wagner <vitus@45.free.net>
 wrote:
> Not only. Typically, on most modern architectures most utilities run a
> bit faster an consume less memory if compiled 32-bit.

Yep, this is true. However, as the architecture is quickly gaining
popularity, I deem it useful to add that on amd64 spesifically this
isn't generally quite true (well, for the speed part anyway).

Of course, this is mostly due to there being more general purpose
registers available in 64-bit mode on that architecture and not any
"64-bit magic" which seems to govern marketing.

-- 
Mikko Rauhala   - mjr@iki.fi     - <URL:http://www.iki.fi/mjr/>
Transhumanist   - WTA member     - <URL:http://www.transhumanism.org/>
Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>

Mikko Rauhala <mjr@iki.fi> wrote:
: isn't generally quite true (well, for the speed part anyway).
: Of course, this is mostly due to there being more general purpose
: registers available in 64-bit mode on that architecture and not any
: "64-bit magic" which seems to govern marketing.

On sparc there is -xarch=v8plus switch for assembler, which allows to
use most of the 64-bit capablities in the 32-bit addressing mode. May be
something simular is available on AMD and would be eventually supported
by compilers.

vitus@45.free.net (Victor Wagner) writes:

>On sparc there is -xarch=v8plus switch for assembler, which allows to
>use most of the 64-bit capablities in the 32-bit addressing mode. May be
>something simular is available on AMD and would be eventually supported
>by compilers.

It's not possible on AMD64.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Mikko Rauhala <mjr@iki.fi> writes:

> On Fri, 20 May 2005 12:56:48 +0000 (UTC), Victor Wagner <vitus@45.free.net>
>  wrote:
>> Not only. Typically, on most modern architectures most utilities run a
>> bit faster an consume less memory if compiled 32-bit.
>
> Yep, this is true. However, as the architecture is quickly gaining
> popularity, I deem it useful to add that on amd64 spesifically this
> isn't generally quite true (well, for the speed part anyway).
>
> Of course, this is mostly due to there being more general purpose
> registers available in 64-bit mode on that architecture and not any
> "64-bit magic" which seems to govern marketing.

The amd64 32-bit mode is an emulation of an old 32-bit x86 CPU,
including all its deficiencies.  The 32-bit mode available on some
other machines is only limiting the address space, while still
providing full 64-bit math etc.

-- 
M�ns Rullg�rd
mru@inprovide.com

M=E5ns Rullg=E5rd wrote:
>=20
> Some 64-bit operating systems can run programs with a 32-bit
> personality, meaning that only 32-bit addresses will be used.  This is
> to make porting of badly written programs assuming 32-bit pointers
> easier.  [...]

    It's also to avoid penalizing programs that can run in
a 4GB address space.  If you don't need more than 4GB, why
should you have to double the amount of memory your program
devotes to pointers, merely to store lots and lots of copies
of 32 constant bits?  All it does is increase the pressure
on your memory caches: A greater number of bytes for the
same "payload" makes the cache miss rates go up while the
instruction execution rate goes down ...

    64-bit pointers open up some possibilities that simply
aren't present in 32-bit land: mapping all the disks in a
data center to fixed virtual addresses, for example.  But
if a program doesn't need such capabilities and won't use
them, it shouldn't be required to take a performance hit.

--=20
Eric.Sosman@sun.com

In comp.protocols.tcp-ip Victor Wagner <vitus@45.free.net> wrote:
> I've collected expermimental data of sizeof for variuous types on
> various platforms on the http://www.45.free.net/~vitus/intsize.html
> There are four 64-bit platforms in the table: FreeBSD on
> AMD/Opteron, Solaris on Sparc64, HP/UX on Itanium 64 and HP/UX on
> PA-RISC 64.

Since I cannot resist a nit:

$ uname -s
HP-UX

> On all these platforms size of POINTER is 64 bit, and Long is 64 bit
> also. But int is still 32 bit for compatibility with most applications.

Those would all be considered "LP64" (L == Long, P == pointer)

> As far as I know, 64-bit Windows (on AMD, Intel E64T, Itanium) goes
> even further - they keep long 32bit and only long long (or int64_t)
> and pointers are 64 bit. Although I've done no experiments.

I've run into that with netperf.  Indeed, "64-bit" Windows is a "P64"
programming model - Pointers are 64 bits.

rick jones
-- 
denial, anger, bargaining, depression, acceptance, rebirth...
                                     where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com  but NOT BOTH...

<myself_rajat@yahoo.com> wrote in message 
news:1116585635.065331.141420@g43g2000cwa.googlegroups.com...

> As we all know, in C, the size of int depends on underlying platform,
> and typically is of 2 bytes or 4 bytes. Whereas the size of long
> dattype is atleast of 4 bytes. I think these things are tru only for 16
> and 32 bit OS, what about 64 bit OS?? Obviously the int size will be of
> 64 bit, but what will be of long size??

    Why is that obvious? Many 64-bit systems has 32-bit integers and 64-bit 
longs.

> Actually I came accross a issue, as in some protocols, some fields are
> of 4 bytes. So for that I used to take unsigned long data type, to read
> and write those 4 bytes. Now what datatype we can use for that in a 64
> bit OS??(if we don't want to use our own procedures for reading/writing
> those 4 bytes in integers).

    If the protocol is defined at the byte level, then you have to encode 
and decode it at the byte level. Shortcuts like you're suggesting are 
platform-specific and may not be possible on some platforms. You should 
always write the generic code first, and if there's a proven performance 
issue, substitute platform-specific optimizations on those platforms where 
the need is proven.

    DS

David Schwartz wrote:
> <myself_rajat@yahoo.com> wrote in message
> news:1116585635.065331.141420@g43g2000cwa.googlegroups.com...
>
> > As we all know, in C, the size of int depends on underlying
platform,
> > and typically is of 2 bytes or 4 bytes. Whereas the size of long
> > dattype is atleast of 4 bytes. I think these things are tru only
for 16
> > and 32 bit OS, what about 64 bit OS?? Obviously the int size will
be of
> > 64 bit, but what will be of long size??
>
>     Why is that obvious? Many 64-bit systems has 32-bit integers and
64-bit
> longs.
>
> > Actually I came accross a issue, as in some protocols, some fields
are
> > of 4 bytes. So for that I used to take unsigned long data type, to
read
> > and write those 4 bytes. Now what datatype we can use for that in a
64
> > bit OS??(if we don't want to use our own procedures for
reading/writing
> > those 4 bytes in integers).
>
>     If the protocol is defined at the byte level, then you have to
encode
> and decode it at the byte level. Shortcuts like you're suggesting are

> platform-specific and may not be possible on some platforms. You
should
> always write the generic code first, and if there's a proven
performance
> issue, substitute platform-specific optimizations on those platforms
where
> the need is proven.
>
>     DS

Thanks to all of you, for sharing your comments on this topic. Now I
have got the idea, exactly what I need.

myself_rajat@yahoo.com wrote:

> and 32 bit OS, what about 64 bit OS?? Obviously the int size will be of
> 64 bit, but what will be of long size??

Most 64 bits Unices use the LP64 model, where int is 32 bits wide.
For an in-depth discussion see:

   http://www.opengroup.org/public/tech/aspen/lp64_wp.htm

-- 
mail1dotstofanetdotdk

Victor Wagner wrote:

> As far as I know, 64-bit Windows (on AMD, Intel E64T, Itanium) goes even
> further - they keep long 32bit and only long long (or int64_t) and
> pointers are 64 bit. Although I've done no experiments.

The so-called P64 model. See:

   http://www.microsoft.com/msj/0798/hood0798.aspx

> BTW, if somebody have a platform or compiler,
> which is not listed in this table, fill
> free to run supplied program and send me a results.

For Tru64 5.1b on Alpha EV7 using Compaq C V6.5-207

   sizeof(char)           = 8 bits
   sizeof(short)          = 16 bits
   sizeof(int)            = 32 bits
   sizeof(long)           = 64 bits
   sizeof(long long)      = 64 bits
   sizeof(float)          = 32 bits
   sizeof(double)         = 64 bits
   sizeof(long double)    = 128 bits
   sizeof(char *)         = 64 bits
   sizeof(char (*)(char)) = 64 bits

-- 
mail1dotstofanetdotdk

Bjorn Reese <breese@see.signature> writes:

>> BTW, if somebody have a platform or compiler,
>> which is not listed in this table, fill
>> free to run supplied program and send me a results.
>
> For Tru64 5.1b on Alpha EV7 using Compaq C V6.5-207
>
>    sizeof(long double)    = 128 bits

So the EV7 has 128-bit long double?  The largest floating point types
on the earlier models is 64 bits, right?

-- 
M�ns Rullg�rd
mru@inprovide.com

M�ns Rullg�rd wrote:

> So the EV7 has 128-bit long double?  The largest floating point types
> on the earlier models is 64 bits, right?

Yes. I believe that EV6 was the first Alpha with 128 bits long double.
I do not have access to EV6; the closest I get is EV56 and EV67, and it
has changed between those two versions.

-- 
mail1dotstofanetdotdk