Re: u/int64 support for glib, status?

[Tim Janik <timj gtk org>]

On 19 Sep 2001, Owen Taylor wrote:

> 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.

before you jump to G_TYPE_INT64 too quickly, i'd rather have you adress my
second note in detail. what makes you think 64bit is going to be supported
by upcoming standards (i'm not saying i'm sure it's _not_ going to be
supported, i'm just not sure it will be). for 8/16/32, i can be pretty sure
because there's a hell of a lot of code out there that relies on having
those sizes.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ