- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: G_TYPE_INT64
- Date: Thu, 4 Oct 2001 03:47:43 +0200 (CEST)
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
> (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
though, i thought we figured that 64bit ints are available
everywhere we run nowadays, so we should prolly simply require that
] [Thread Prev