Re: u/int64 support for glib status?

[Daniel Egger <egger suse de>]

On Don, 2001-09-20 at 00:06, Tim Janik wrote:

> i'd really like to get this in, and it can be done fairly
> quickly. there are two issues currently stopping me from doing it:
> 1) what should the name be? G_TYPE_INT64 might be a bad choice, what's
>    going to happen for the first 128bit cpu?

What't the problem with G_TYPE_INT64? It represents an 64bit wide
nonfloat value, I think it's pretty obvious and for 128bit CPUs
it would be G_TYPE_INT128 (though I think there'll be no 128bit cpu
for quite some time since there's not really a need for it).

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

I don't think it'll ever happen that a compiler randomly chooses the
size of a type and as long as it's possible to tell every compiler on
earth how big the wanted quantity should be there shouldn't be a big 
problem to guarrantee that a G_TYPE_INT64 will be indeed a 64bit type -
which is obviously the primary goal of providing platform independent
type definitions.

> 2) i don't want to get my head pulled off for making glib/gtk depend hardly
>    on 64bit on a solo ride. so i'd like to see consensus here that we'll
>    make that move and stand by it.

At the moment I fail to see the drawback of providing such a type. If a 
compiler simply has no support for it and some application requires it
we still have two options:
- Emulate 64bit in glib
- Bail out with an error

--
Servus,
       Daniel