[gmx-developers] 64bit integers
hess at cbr.su.se
Mon Jul 13 10:12:51 CEST 2009
There is a gmx_step_t defined in include/types/simple.h which is 64 bit
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.
More information about the gromacs.org_gmx-developers