Coding standards for 32/64-bits data

[OBATA Akio]

On Wed, 29 Jun 2011 22:32:23 +0900, Bron Gondwana <brong at 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 / obata at lins.jp