Coding standards for 32/64-bits data
julien.coloos at atosorigin.com
Wed Jul 6 08:46:53 EDT 2011
Le 29/06/2011 15:32, Bron Gondwana a écrit :
> On Wed, Jun 29, 2011 at 02:21:17PM +0200, Julien Coloos wrote:
>> Hi there,
>> 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)
>> - 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.
In that case, should there be some kind of fallback for people using
compilers that do not support C99 ?
Because while there should not be much issues concerning the existence
of (u)intXX_t types, the macro format specifiers usually defined in
inttypes.h (e.g. PRId64 and PRIu64 for signed/unsigned 64-bits number)
may not be present.
From time to time I like to do such changes, leaving aside "legacy"
stuff. But people that are not up-to-date with standards may not like it
as much as I do ;)
More information about the Cyrus-devel