[gmx-developers] 64bit integers

Sun Sep 6 15:57:04 CEST 2009

Oops.. that only works in hexadecimal.

Sander

On Sep 6, 2009, at 15:55 , Sander Pronk wrote:

> you're right; if it's only found in smalloc.c, you could try, as a  
> real hack:
>
> size_t sz;
>
> #if (SIZEOF_SIZE_T > SIZEOF_INT)
> printf("%u%u", sz >> (SIZEOF_INT*8), (unsigned int)sz);
> #else
> printf("%u",sz);
> #endif
>
> with some additional code to leave out any leading zeroes if that's  
> important to you.
>
> Sander
>
>
> On Sep 6, 2009, at 12:00 , Roland Schulz wrote:
>
>> 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
>> _______________________________________________
>> 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.

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