Re: G_TYPE_INT64

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

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

Well, the difference is not big and it's not hard to fix up.

> also, not all uses of gint64 are special cased in the version
> you sent.

Read above.

> though, i thought we figured that 64bit ints are available
> everywhere we run nowadays, so we should prolly simply require that
> in configure.in.

I don't see any particular point in that - read above.

Regards,
                                        Owen