[gmx-developers] 64bit integers
hess at cbr.su.se
Mon Jul 13 10:36:32 CEST 2009
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
Berk Hess wrote:
> 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.
> Erik Lindahl wrote:
>> 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:
>>> 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.
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> 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
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
More information about the gromacs.org_gmx-developers