ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

>Hallvard B Furuseth <h.**********@usit.uio.nowrote:
>>Keith Thompson <ks***@mib.orgwrites:
>>>

define IMAX_BITS(m) ((m) /((m)%0x3fffffffL+1) /0x3fffffffL %0x3fffffffL *30 \

+ (m)%0x3fffffffL /((m)%31+1)/31%31*5 + 4-12/((m)%31+3))

>>And add 1 for the sign bit if the argument is for a signed type.

If the argument is a signed type, then the sign of (-1) % %0x3fffffffL

is not nailed down (at least not by C89).

Hm, that thread seems to be missing the documentation. It returns #bits

in inttype_MAX, or in any (1<<k)-1 where 0 <= k < 3.2E+10. E.g.

IMAX_BITS(INT_MAX) + 1 for #bits in the value INT_MAX, + 1 for sign bit.

Except...

>>And add 1 for the sign bit if the argument is for a signed type.

That presumes that there is a seperate sign bit, and exactly one of

them. C89 does not promise either;

Hmm. I think it does promise separate sign bit(s), since "The range of

nonnegative values of a signed integer type is a subrange of the

corresponding unsigned integer type, and the representation of the same

value in each type is the same." (ANSI draft, 3.1.2.5p5.)

I never thought of multiple sign bits though. Yuck. Does that mean

that we can have (a == INT_MIN && b == INT_MIN && (a & b) == 0)? a and

b could have different sign bits set - two's complement except that

there are several sign bit and a value is negative if at least one sign

bit is negative. Anyway, I can't say I'll worry about such a beast

until I hear about one:-)

C99 is a bit tighter on this, but not enough so that a constant +1

would work.

Huh? C99 6.2.6.2p2: For signed integer types (...) there shall be

exactly one sign bit.

BTW, I posted a bunch of macros for log2() of any positive constant

integer some time ago too, but that was several lines of macros calling

each others, yielding one _huge_ expression.

http://groups.google.com/group/comp....6324f25e4a60b0
--

Hallvard