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