Coding standards for 32/64-bits data

[Alexey Melnikov]

[A very late comment in support of this proposal.]

Julien Coloos wrote:
> 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.
I agree with this. In general I prefer use of [u]int{16|32|64}_t on all 
platforms.
> 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.
I know that unit64_t is not defined in inttypes.h on Windows, but I am 
still Ok with using it there (e.g. inside Cyrus SASL). Platforms that 
don't have native support for these data types can still define them.
> >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 ;)