[gmx-developers] 64bit integers

[Berk Hess]

Hi,

There is a gmx_step_t defined in include/types/simple.h which is 64 bit
when possible.
But for this case I would simply use long long int for the moment,
which will be 64 bit in nearly all cases.

Berk

Erik Lindahl wrote:
> Hi,
>
> Gromacs 4.1 won't require 64 bit support, but Gromacs 5 will (we will
> have gmx_int64_t, etc.).
>
>
> On Jul 10, 2009, at 6:42 PM, Roland Schulz wrote:
>
>> Hi,
>>
>> which integer type should be used for integers that should be 64bit
>> if available.
>>
>> My current problem: ndim*ndim*4 in gmx_covar overflows for more than
>> 7723 atoms.
>>
>> One could use:
>> - long (is only 32bit on windows)
>> - long long (is always 64bit, not defined in C89)
>> - size_t (is the size of pointer)
>> - same typedef
>>
>> - One shouldn't use long, since it wouldn't solve it on windows.
>> - Using "long long" is slow (in this case unimportant) and will give
>> warning when passed to snew or memcpy.
>> - size_t doesn't seem very clean and will give warnings when passed
>> to printf (unless first upcasting to "unsigned long long" and then
>> using %llu).
>>
>> Is C89 support required?
>> Is it OK to use size_t for those integers?
>>
>> What is the best option?
>
> I would use size_t since that is ISO C at least. Check
> include/types/simple.h - Berk has added some formats for printing
> steps, that we should also augment to include windows, and change so
> they aren't so step-specific.
>
>
>>
>> BTW: Is it OK to change save_calloc and save_realloc to size_t
>> (currently "unsigned")?
>
> Yes, that would agree better with ISO C.
>
> Cheers,
>
> Erik
>
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use thewww
> interface or send it to gmx-developers-request at gromacs.org.