Interfacing with c and platform dependent sizes

[Jacob Carlborg]

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

> In any case, if you really don't know the code and don't want to take the time
> to understand it, I'd use int for int, long for long long, and then if they have
> long, I'd do the research to figure out which OS and architecture the code is
> supposed to be for and use int if long long is 32 bits and long if it's 64 bits.
> If you don't know what system it was built for, then I'd probably just use long
> and hoped that they weren't doing anything that made using an integral type
> which was too large a problem.
>
> - Jonathan M Davis


-- 
/Jacob Carlborg