Coding standards for 32/64-bits data

[Bron Gondwana]

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.