Interfacing with c and platform dependent sizes

Jonathan M Davis jmdavisProg at gmx.com
Sat Feb 26 03:20:28 PST 2011


On Saturday 26 February 2011 02:51:08 Jacob Carlborg wrote:
> On 2011-02-26 02:35, Jonathan M Davis wrote:
> > On Friday, February 25, 2011 17:16:31 simendsjo wrote:
> >> On 26.02.2011 02:06, bearophile wrote:
> >>> simendsjo:
> >>>> So.. A long in C is the same as the platform size? And long long
> >>>> doesn't exist in 64 bit?
> >>> 
> >>> In D the size of int/uint is 32 bits and long/ulong is 64 bits.
> >>> 
> >>> In C the size of int, unsigned int, long, long long int, unsigned long
> >>> long int, etc are not fixed, the change according to the CPU.
> >>> sizeof(int)<= sizeof(long)<= sizeof(long long).
> >>> 
> >>> A help:
> >>> http://www.digitalmars.com/d/2.0/phobos/std_stdint.html
> >>> 
> >>> Bye,
> >>> bearophile
> >> 
> >> Ouch.. Any tips on porting C code that would work nicely with a
> >> transition to 64 bit?
> >> Should I change all long and int to int_atleast_32_t and long long to
> >> 64?
> > 
> > It depends entirely on what the code is doing. It could be completely
> > safe to convert all ints, longs, and long longs to long to long. Or you
> > may have to choose int or long depending on what system the code is
> > supposed to be for.
> > 
> > In many cases, using a larger type wouldn't matter, since it can hold
> > more than the smaller type, so whether the type in C/C++ was 32 bits or
> > 64 bits is irrelevant. In other cases, the type needs to be an exact
> > size, because the code is doing bit shifts or whatnot (in which case
> > they _should_ have been using int32_t and int64_t on Linux and whatever
> > the equivalent is on Windows, but unfortunately, many programmers
> > don't). And if you're dealing with a struct, it's possible that that
> > struct has to be an exact size (e.g. for some binary format), and using
> > the wrong type in converting could make it the wrong size.
> > 
> > If you want to know what the appropriate D type is for the C/C++ code,
> > you _need_ to know what it does.  Now, IIRC, int is almost guaranteed to
> > be 32 bits at this point, and long long is essentially guaranteed to be
> > 64 bits, but long varies from system to system - both in terms of OS and
> > architecture. IIRC, long is 32 bits on Solaris and Windows - both on x86
> > and x86_64 - but it's 32 bits in x86 Linux and 64 bits in x86_64 Linux.
> > So, if all the code uses is int and long long, then it's probably
> > reasonably safe to use int for int and long for long long, but it's
> > ultimately system dependent. Personally, I would argue that C/C++ code
> > should use int when you don't care about the size of an integral type
> > and use the intX_t types (where X is 8, 16, 32, or 64) when you _do_
> > care about the size, but there's no guarantee that programmers are going
> > to be that disciplined about it.
> 
> A C "long" is 64bit long on Solaris 64bit according to this:
> http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models

Well, I've run into problems before due the size of long differing on Linux and 
Solaris and I thought that it was 64-bit Linux and 64-bit Solaris, but maybe it 
was actually 32-bit Solaris (I _know_ that it was 64-bit Linux though). 
Regardless, it just goes to show how careful you have to be when dealing with 
long in C and C++.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list