[gmx-developers] 64bit integers

Roland Schulz roland at utk.edu
Sun Sep 6 12:00:30 CEST 2009


well under windows long is only 32 bit. Also size_t is usually unsigned.

should we cast it to gmx_step_t (or some type derived from it) and then
print it?

On Sun, Sep 6, 2009 at 5:01 AM, Sander Pronk <pronk at cbr.su.se> wrote:

> I think that would be %zd according to C99. It's probably safer to use %ld,
> because it's C89 compliant (not all compilers support C99), and it happens
> to coincide with the width of size_t on all platforms I know of.
>
> Sander
>
>
> On Sep 6, 2009, at 06:33 , Roland Schulz wrote:
>
> Hi,
>
> in smalloc %u is used for size_t. This is not correct. Is it OK to change
> this to the correct %z? I'm asking, because I don't know whether it is
> supported by all compilers.
>
> Roland
>
> On Mon, Jul 13, 2009 at 4:36 AM, Berk Hess <hess at cbr.su.se> wrote:
>
>> 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.
>> >
>>
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309
> _______________________________________________
> 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.
>
>
>
> _______________________________________________
> 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.
>



-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20090906/d2eaf203/attachment.html>


More information about the gromacs.org_gmx-developers mailing list