Re: G_TYPE_INT64

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

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

Basically, the situation is pretty simple: 
  
 - No code for int64 support in gobject in CVS, no progress.
 - Code for int64 support in gobject in CVS, can be fixed.

This not being something that I have much code around to test, 
and since you were not around, I decided that the best
way of proceeding was to commit what we had, which was on
examination correct at least as far as it went, and to let
people tell me what was missing.

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

Oh no, I left out a #ifdef! /me buries head in sand. On second
though, he spends all of 3 seconds to fix it.
 
> > > 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.

The quote was:

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

There was a long thread which didn't seem particularly conclusive -
conditionalizing was easy. So I did it.

Regards,
                                        Owen