On Wed, Jun 29, 2011 at 02:21:17PM +0200, Julien Coloos wrote: > Hi there, > > I am currently wondering how to properly handle (ex-32/)64-bits data > in cyrus code. Since this may be useful for other developpers > willing to contribute to cyrus, I am asking on the mailing list > instead of IRC channel (that I have yet to join actually). > > In previous versions of cyrus, some data could be 32 or 64-bits > depending on the architecture. For example the quota value (and the > associated printf format) was 64-bits if HAVE_LONG_LONG_INT was > defined, 32-bits otherwise. To limit the impact on source code, > typedef and #define was used: > #ifdef HAVE_LONG_LONG_INT > typedef unsigned long long int uquota_t; > typedef long long int quota_t; > #define UQUOTA_T_FMT "%llu" > #define QUOTA_T_FMT "%lld" > #define QUOTA_REPORT_FMT "%8llu" > #else > typedef unsigned long uquota_t; > typedef long quota_t; > #define UQUOTA_T_FMT "%lu" > #define QUOTA_T_FMT "%ld" > #define QUOTA_REPORT_FMT "%8lu" > #endif > > I used the same scheme for ticket 3374 (selection of most fitting > partition/backend) where I had to handle the partition/backend disk > size. > But it appears a few months ago 64-bits support became mandatory in > master, and in the case of quota only the typedef and #define of the > 64-bits section were kept. > Leaving aside legacy data, the question is how to handle new ones > (like the feature I worked on) ? Should we: > - keep on using typedef and #define, even if we now only use > 64-bits types: in that case it is easier to change the data type if > needed (Who will ever need more than 640kB memory ? ;p) > or > - just use plain "(unsigned) long long / (u)int64_t" types and > associated printf formats
I vote for using (u)int64_t and associated formats everywhere. And stripping all the other stuff. I did an informal poll and discovered that approximately nobody compiles anywhere that doesn't offer a longlong type. Even on 32 bit platforms. The future is now people. Bron.
