Re: u/int64 support for glib, status?

[Owen Taylor <otaylor redhat com>]

vishnu pobox com writes:

> On Thu, Sep 20, 2001 at 12:06:16AM +0200, Tim Janik wrote:
> > 1) what should the name be? G_TYPE_INT64 might be a bad choice, what's
> >    going to happen for the first 128bit cpu? does it come with long long long,
> >    or will the compiler people simply resize long long integer to 128bit?
> >    so i'd lean towards something like G_TYPE_BIGUINT and guarantee that
> >    it's >= 64bit. though the name is a bit silly ;)
> 
> Agreed, the type name should not contain a bit count.  After all,
> none of the other fundemental type names contain a bit count.
> 
> signed   unsigned
> -------- ----------
> quad     uquad         unintuitive (implies a single is 16 bits)
> bigint   biguint       fine, but strange to have 'u' in the middle
> bigint   ubigint       fine
> llong    ullong        fine -- similar to <limits.h> defines

G_TYPE_INT64 is a fine name. 

 - 64 bit is what people want, not "the biggest damn numbers the platform
   has" If a platform is 64 bit, there is no  reason to use slow 128-bit 
   integers if it has them. 

 - We have gint64, we don't have gllong, or gquad.

 - If we use long long, not a 64 bit integer, we have a risk of making
   GValue twice as big if long long is longer than double.

Regards,
                                        Owen