The hack is cool. I guess the best is:<br>size_t sz;<br>printf(gmx_step_pfmt,(gmx_step_t)sz);<br><br>(We will rename gmx_step_t in gmx_long_t or gmx_int64_t. This might upcast it from 32 to 64bit but that does not hurt. I wrote this before but without example it was not understanble)<br>
<br><br><div class="gmail_quote">On Sun, Sep 6, 2009 at 9:57 AM, Sander Pronk <span dir="ltr"><<a href="mailto:pronk@cbr.su.se">pronk@cbr.su.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">Oops.. that only works in hexadecimal. <div><br></div><font color="#888888"><div>Sander</div></font><div><div></div><div class="h5"><div><br><div><div>On Sep 6, 2009, at 15:55 , Sander Pronk wrote:</div><br>
<blockquote type="cite"><div style="">you're right; if it's only found in smalloc.c, you could try, as a real hack:<div><br></div><div>size_t sz;</div><div><br></div><div>#if (SIZEOF_SIZE_T > SIZEOF_INT)</div>
<div>
printf("%u%u", sz >> (SIZEOF_INT*8), (unsigned int)sz);</div><div>#else</div><div>printf("%u",sz);<br><div>#endif</div><div><br></div><div>with some additional code to leave out any leading zeroes if that's important to you.</div>
<div><br></div><div>Sander </div><div><br></div><div><br><div><div>On Sep 6, 2009, at 12:00 , Roland Schulz wrote:</div><br><blockquote type="cite">well under windows long is only 32 bit. Also size_t is usually unsigned. <br>
<br>should we cast it to gmx_step_t (or some type derived from it) and then print it?<br><br><div class="gmail_quote">On Sun, Sep 6, 2009 at 5:01 AM, Sander Pronk <span dir="ltr"><<a href="mailto:pronk@cbr.su.se" target="_blank">pronk@cbr.su.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div>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. </div>
<div><br></div><font color="#888888"><div>Sander</div></font><div><div></div><div><div><br></div><br><div><div>On Sep 6, 2009, at 06:33 , Roland Schulz wrote:</div><br><blockquote type="cite">Hi,<br><br>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.<br>
<br>Roland<br><br><div class="gmail_quote"> On Mon, Jul 13, 2009 at 4:36 AM, Berk Hess <span dir="ltr"><<a href="mailto:hess@cbr.su.se" target="_blank">hess@cbr.su.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br> <br> long long int might not exist on some architectures.<br> To be really on the safe side, you should define a new type using<br> the same checks as for gmx_step_t, or simply define a new type using<br> gmx_step_t.<br>
<font color="#888888"><br> Berk<br> </font><div><div></div><div><br> Berk Hess wrote:<br> > Hi,<br> ><br> > There is a gmx_step_t defined in include/types/simple.h which is 64 bit<br> > when possible.<br> > But for this case I would simply use long long int for the moment,<br>
> which will be 64 bit in nearly all cases.<br> ><br> > Berk<br> ><br> > Erik Lindahl wrote:<br> ><br> >> Hi,<br> >><br> >> Gromacs 4.1 won't require 64 bit support, but Gromacs 5 will (we will<br>
>> have gmx_int64_t, etc.).<br> >><br> >><br> >> On Jul 10, 2009, at 6:42 PM, Roland Schulz wrote:<br> >><br> >><br> >>> Hi,<br> >>><br> >>> which integer type should be used for integers that should be 64bit<br>
>>> if available.<br> >>><br> >>> My current problem: ndim*ndim*4 in gmx_covar overflows for more than<br> >>> 7723 atoms.<br> >>><br> >>> One could use:<br> >>> - long (is only 32bit on windows)<br>
>>> - long long (is always 64bit, not defined in C89)<br> >>> - size_t (is the size of pointer)<br> >>> - same typedef<br> >>><br> >>> - One shouldn't use long, since it wouldn't solve it on windows.<br>
>>> - Using "long long" is slow (in this case unimportant) and will give<br> >>> warning when passed to snew or memcpy.<br> >>> - size_t doesn't seem very clean and will give warnings when passed<br>
>>> to printf (unless first upcasting to "unsigned long long" and then<br> >>> using %llu).<br> >>><br> >>> Is C89 support required?<br> >>> Is it OK to use size_t for those integers?<br>
>>><br> >>> What is the best option?<br> >>><br> >> I would use size_t since that is ISO C at least. Check<br> >> include/types/simple.h - Berk has added some formats for printing<br>
>> steps, that we should also augment to include windows, and change so<br> >> they aren't so step-specific.<br> >><br> >><br> >><br> >>> BTW: Is it OK to change save_calloc and save_realloc to size_t<br>
>>> (currently "unsigned")?<br> >>><br> >> Yes, that would agree better with ISO C.<br> >><br> >> Cheers,<br> >><br> >> Erik<br> >><br> >> _______________________________________________<br>
>> gmx-developers mailing list<br> >> <a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br> >> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
>> Please don't post (un)subscribe requests to the list. Use thewww<br> >> interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
>><br> ><br> > _______________________________________________<br> > gmx-developers mailing list<br> > <a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br> > <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
> Please don't post (un)subscribe requests to the list. Use the<br> > www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
><br> <br> _______________________________________________<br> gmx-developers mailing list<br> <a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br> </div></div>
</blockquote></div><br><br clear="all"><br>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br> _______________________________________________<br>
gmx-developers mailing list<br><a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br><a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the <br>www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>
<br></div></div></div><br>_______________________________________________<br> gmx-developers mailing list<br> <a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br></blockquote>
</div><br><br clear="all"><br>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br> 865-241-1537, ORNL PO BOX 2008 MS6309<br> _______________________________________________<br>
gmx-developers mailing list<br><a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br><a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the <br>www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>
<br></div></div></div>_______________________________________________<br>gmx-developers mailing list<br><a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br><a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the <br>www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>
<br></div></div></div></div><br>_______________________________________________<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br><br clear="all"><br>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>
865-241-1537, ORNL PO BOX 2008 MS6309<br>