Re: u/int64 support for glib status?

[Tim Janik <timj gtk org>]

On 19 Sep 2001, Owen Taylor wrote:

> I don't have a huge opinion on this subject, since I'm probably
> never going to use 64 bit ints, and certainly not for GValue :-)
> 
> One issue we have here is that if we did this, we'd basically probably
> want to make int64 support mandatory ... I don't see extending the
> hunk of API we have conditionalized with G_HAVE_GINT64.
> 
> Now, I suspect the vast majority of compilers used on Unix either have
> compiler support for long long because they are GCC, or because they
> are recent. I don't have any particular stats on this, however.
> 
> What about windows compilers? Do MSVCC and the Borland compiler
> support a 64bit long long?
> 
> I put in on the future milestone because:
> 
>  - As long as gint64 is conditionalized, apps are going to have
>    trouble depending on it.
>  - It's something that can be later without compatibility problems
>  - I don't see it as a real pressing API lack compared to other
>    issues we have.
>  - The more stuff we can _not_ put in 2.0.0, the happier I am :-)
> 
> But if there is a strong feeling we should put such support in, I'm
> not going to raise a huge fuss. Just as long as we quickly resolve it
> one way or the other. Tim?

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

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ