Coding standards for 32/64-bits data

Julien Coloos 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)
>> 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.

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 ;)


Regards


More information about the Cyrus-devel mailing list