On Wed, 29 Jun 2011 22:32:23 +0900, Bron Gondwana <br...@fastmail.fm> wrote:
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.
For ticket 3376 (time_t != unsigned long), I would be helpful if TIME_T_FMT is
also introduced.
(or use fixed type (uint64_t?) for network protocol/database timestamp instead
of time_t?)
--
OBATA Akio / ob...@lins.jp
