BITAND, etc. - what about bit limits/sign bit? Gnumeric folks, willingto change what they do?

["David A. Wheeler" <dwheeler@dwheeler.com>]

I've been fiddling with Gnumeric, and have found an unwelcome and
undocumented "feature" of Gnumeric's BITAND, BITOR, etc.
Basically, they presume that all values are 32-bit SIGNED values,
and they only produce 32-bit signed values.
Bit position 32 (counting from 1=LSB) is always the sign bit,
which fundamentally limits the largest size they can handle.

That's really annoying.  As computers get bigger, I'd hate to be
limited to 32-bit values.  Indeed, I think most implementations
use IEEE 754 doubles, so you can get more bits RIGHT NOW,
and 48 bits are actually very useful.  And getting negative numbers
when bit position 32 is 1 is not always what you want!

So we have three options:
1. Spec what Gnumeric does (w/sign bit).  But this will greatly constrain
    future implementations in an unfriendly way.  I don't like that option.
2. Spec that what Gnumeric does is wrong in this case - don't have
    "sign" values in any particular position.  Then require
    that positive values be supported up to some large value
    (say 2^48-1, or 2^50-1).  This would impose a change
    on Gnumeric that they may think is not appropricate.
    Gnumeric folks, any comment?
3. Add a "portable constraint", saying that they take
    values 0 <= N <= 2^31-1.  Then what happens
    beyond those ranges is implementation-defined.

Number 3 is the easiest.  Number 2 is the cleanest long-term.

Comments? Thoughts?  I'd like to hear from the Gnumeric
developers in particular, but I'd like to hear from anyone.

--- David A. Wheeler