[gmx-developers] 64bit integers

[Berk Hess]

Hi,

long long int might not exist on some architectures.
To be really on the safe side, you should define a new type using
the same checks as for gmx_step_t, or simply define a new type using
gmx_step_t.

Berk

Berk Hess wrote:
> 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.
>>     
>
> _______________________________________________
> 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 the 
> www interface or send it to gmx-developers-request at gromacs.org.
>