Re: G_TYPE_INT64
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: G_TYPE_INT64
- Date: 03 Oct 2001 22:37:39 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]