Re: G_TYPE_INT64

[Tim Janik <timj gtk org>]

On 1 Oct 2001, Owen Taylor wrote:

> 
> I'd like to commit the following patch to add G_TYPE_INT64 and
> resolve bug #59254.
> 
>  - I've gone with int64 as a name, because:
>  
>     - I think it is the right thing to do. (See my earlier mails.)
>     - There were no decent names proposed as an alternative.
>       (G_TYPE_LONGLONG would only make sense if we had glonglong,
>       most of the rest were worse.)
> 
>  - The support is conditionlized on the idea that if you don't have int64 
>    support, there is nothing you can do about it, so we might as
>    well allow you to build the parts of GLib you can.
> 
>    (This is different from something like iconv() or gettext() where
>    you can install an additional library to get the functionality.)
> 
>  - The unconditionized parts are intentionally left unconditionalized
>    so that enum values don't depend on whether you have int64 support
>    or not. 
> 
> I'd like to commit within the next day or two, so please get back
> to me quickly if you have problems with the change or the
> patch.
> 
> (The patch is Mathieu's, conditionalized with G_HAVE_GINT64, and
> with int8/16/32 support removed.)

this is not an int64 fundamental type implementation, it just
implements a param spec for it, as i outlined in my original
commentary on matthieus patch.
also, not all uses of gint64 are special cased in the version
you sent.
though, i thought we figured that 64bit ints are available
everywhere we run nowadays, so we should prolly simply require that
in configure.in.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ