Re: G_TYPE_INT64

[Tim Janik <timj gtk org>]

On 3 Oct 2001, Owen Taylor wrote:

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

eh? the patch like you posted it is fundamentally broken in that
it specifies a fundamental type for INT64 and UINT64 but never registered it.
there's no point in comitting this before an actuall fundamental type
implementation is actually there. that's just like committing
void gtk_widget_foo (void);
void gtk_widget_bar (void);
void gtk_widget_baz (void);
one day without actual implementations.

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

what above? you wrote nothing related above.
if you refer to your original mail that i quoted, you just said you
left enum values unconditionalized, but i'm talking about using the
type _gint64_ unconditionalized.

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

what above? the quote again? i certainly read that, my question
remains though. what's the point in special casing 64bit nowadays?
we've had a huge thread on that, and unless i actually see someone
telling me they have no 64bit type whatsoever, i'd rather require
it and have people provide build fixes for systems where 64bit ints
are not named long long.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ