[gmx-developers] 64bit integers

Sander Pronk pronk at cbr.su.se
Sun Sep 6 11:01:53 CEST 2009


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20090906/b74c9e92/attachment.html>


More information about the gromacs.org_gmx-developers mailing list