Re: u/int64 support for glib status?

[Erik Walthinsen <omega temple-baptist com>]

On Thu, 20 Sep 2001, Tim Janik wrote:

> 1) what should the name be? G_TYPE_INT64 might be a bad choice, what's
>    going to happen for the first 128bit cpu? does it come with long long long,
>    or will the compiler people simply resize long long integer to 128bit?
>    so i'd lean towards something like G_TYPE_BIGUINT and guarantee that
>    it's >= 64bit. though the name is a bit silly ;)

The whole int/long/longlong naming scheme doesn't make much sense to me,
because a) it doesn't scale, and b) it doesn't mean anything except the
machine register size, generally.  That said, it does have relevance.  How
about we stick with either the int/longlong scheme or the uint32/uint64
scheme, and #define one to the other?  That way users who don't care just
use int and get register-side values, and those who do can specify the
size they need.  Not sure which set would be the 'real' set, but I'd lean
towards the dumb/nonscalable names (<g>) because they're what already
exist, and have the most relation to the idea that int/long are
register-sized quantities.  Then if int64 has to be conditional, it's just
a matter of some #defines in a #ifdef or two (roughly, I haven't looked at
the patch too carefully yet).

Just a thought, dunno how sane or not.

      Erik Walthinsen <omega temple-baptist com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_