Re: u/int64 support for glib, status?

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

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

C99 guarantees that there will be a type of _at least_ 64 bits.

While C99 doesn't guarantee that there will be a type of width
64 any more than it guarantees that there will be a type of 
width 8, 16, or 32, I think it's a pretty safe bet that processors
that have >= 64 bit types will have 64 bit types. 

Making types wider isn't free and 64 bits will be enough for memory
addressing for many, many, many years, so we can expect that 
processors will be dealing with 64 bit quantities.

And I don't think the hypothetical 128 bit-only processor is worth
worrying about; it's easy enough to chop down arithmetic calculations
to a smaller size, and we won't be the only people expecting 64 bit
types. So, if there are such processors, there will still be 64 bit
support in the compilers.

And finally, if we have such a hypothetical problem, we can make
g_value_set_int64 behave _as if_ the storage was 64 bits by 
truncating off the high part....

Regards,
                                        Owen