Re: u/int64 support for glib status?



On Thu, 20 Sep 2001, Tim Janik wrote:

> the thing is that we'll have to maintain these types into eternity.
> we'll already have a major problem if a compiler one day wants to get
> rid of any of 8bit, 16bit or 32bit integer types. though i'd consider
> that a ridiculous undertaking and consider such a compiler (even if beefed
> up for some 256bit machine) a failure right from the start.
> i can't make that assumption for long / 64bit though, as "long" is already
> differently sized on various compilers/platforms, and "long long" meaning
> 64bit is somewhat non-standard still. so in any case, we'll just have a
> SOMETHINGINT that'll be >=64bit, not ==64bit, and once we're there, we'd
> better not call it "64"something, but name it in a way that indicates
> it's just bigger than 64bit.

I'm not suggesting that we have int8, int16, etc., unless we're targetting
machines of those width (which afaik we aren't).  But you quite accurately
explain why the int/long/longlong think doesn't make any sense or scale.
The definitions of them are totally up to the machine/compiler in
question, and so they mean nothing in the larger sense.  I thought I saw a
page somewhere a year or so ago that proposed a final naming scheme for
these things, but whether it goes to 256 bits or not I dunno.

However, what I'm proposing is that we stick with the existing names, and
provide types which are guaranteed to be a certain number of bits long (or
longer).  That means that we have BIGINT types or something, if they
exist, and we #define or otherwise map INT64 to that.  If in a decade we
have 256bit machines that don't have even a 64-bit type (unlikely, I'd
think), then INT64 just gets mapped to the 128-bit type.

I just don't like the idea of everyone "KNOWING" that a BIGINT is 64 bits,
just because, um, well, it *is*.  If I need to have 64 bits of data, I
would like to specify that I need 64 or more bits of data explicitly.
Most people won't care, and thus use INT or BIGINT as they wish, and use
the param limits for what they're designed for.

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







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]