number of bits for an int type

[evangeli]

Hello,
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

thanks

[santosh]

[e-mail] wrote:

Hello,
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

thanks

Yes. However note that except for the type unsigned char, not all the
constituent bits of other types may be value bits, (i.e. bits which
hold the numeric value stored in the variable). There may be one or
more padding and trap bits.

So the range of values representable by the type need not be related to
the value returned by sizeof(T) * CHAR_BIT where T is the type. For
knowing the range, use the macros in <limits.hand <float.h>.

[evangeli]

santosh a écrit :

[e-mail] wrote:

Hello,
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

thanks

Yes. However note that except for the type unsigned char, not all the
constituent bits of other types may be value bits, (i.e. bits which
hold the numeric value stored in the variable). There may be one or
more padding and trap bits.

So the range of values representable by the type need not be related to
the value returned by sizeof(T) * CHAR_BIT where T is the type. For
knowing the range, use the macros in <limits.hand <float.h>.

thanks for your help,
in my program I manipulate many objects that I store in a dictionnary.
to save memory I encode these objects in arrays of ints before
inserting them in the dictionnary.
so is it right to assume that in each element of my array I have
"sizeof(int) * CHAR_BIT" bits?

[santosh]

ev******@cnam.fr wrote:

santosh a écrit :

[e-mail] wrote:

Hello,
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?
>
thanks

Yes. However note that except for the type unsigned char, not all the
constituent bits of other types may be value bits, (i.e. bits which
hold the numeric value stored in the variable). There may be one or
more padding and trap bits.

So the range of values representable by the type need not be related to
the value returned by sizeof(T) * CHAR_BIT where T is the type. For
knowing the range, use the macros in <limits.hand <float.h>.

thanks for your help,
in my program I manipulate many objects that I store in a dictionnary.
to save memory I encode these objects in arrays of ints before
inserting them in the dictionnary.
so is it right to assume that in each element of my array I have
"sizeof(int) * CHAR_BIT" bits?

Yes.

You might also want to read through:
http://c-faq.com/

[Frederick Gotham]

posted:

Hello,
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

Do a google search for IMAX_BITS.

IMAX_BITS is a macro which will tell you how many value representation bits
you have for a given integer value. For instance, if we had a 40-Bit int, 8
bits of which were padding bits, and 32 bits of which were value bits, then
the following would evaluate to the following:

sizeof(unsigned) == 40 / CHAR_BIT

IMAX_BITS( (unsigned)-1 ) == 32

--

Frederick Gotham

[CBFalconer]

ev******@cnam.fr wrote:

>
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

No, because there may be trap bits involved. However the number
range designated by INT_MIN and INT_MAX will give you the answer.
For unsigned int all you need is UINT_MAX. These are all defined
in <limits.h>.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

ev******@cnam.fr wrote:

>>
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

No, because there may be trap bits involved. However the number
range designated by INT_MIN and INT_MAX will give you the answer.
For unsigned int all you need is UINT_MAX. These are all defined
in <limits.h>.

Correction: padding bits, not trap bits. (Padding bits may or may not
contribute to trap *representations*.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Frederick Gotham said:

posted:

>Hello,
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

Do a google search for IMAX_BITS.

IMAX_BITS is a macro which will tell you how many value representation
bits you have for a given integer value.

Chapter and verse, please. I can find no reference to this macro in the ISO
C Standard (either C90 or C99).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard]

Richard Heathfield <in*****@invalid.invalidwrites:

Frederick Gotham said:

> posted:

>>Hello,
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

Do a google search for IMAX_BITS.

IMAX_BITS is a macro which will tell you how many value representation
bits you have for a given integer value.

Chapter and verse, please. I can find no reference to this macro in the ISO
C Standard (either C90 or C99).

Because its a home made macro discussed previously. Its in google.

Takes about 0.001 of a second for google to locate it.

Clever too : considering its calculating the number of bits for an int
*VALUE* and not the int type ......

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Frederick Gotham said:

> posted:

>>Hello,
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

Do a google search for IMAX_BITS.

IMAX_BITS is a macro which will tell you how many value representation
bits you have for a given integer value.

Chapter and verse, please. I can find no reference to this macro in the ISO
C Standard (either C90 or C99).

http://groups.google.com/group/comp....489b673063404c

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

(I don't think there was any claim that it's defined in the standard.)

See the rest of the thread in comp.std.c for some discussion. (I
haven't tried using it myself.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Hallvard B Furuseth]

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.

--
Hallvard

[Walter Roberson]

In article <hb*************@bombur.uio.no>,
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). It could just give you
-1 back as the result. Add 1 to that in the ((m)%0x3fffffffL+1)
expression and you get 0, so you would be dividing m by 0... at
which point you are lost.

If you adjust the mod expressions by changing expressions of the
form t % n into (t + n) % n, then you get around the division by 0,
but you then immediately run into the problem that -1 divided by
anything larger than 1 is going to be 0. Unless your representation
of -1 is exceedingly small, IMAX_BITS() feed a signed 1 is
always going to return the result 79.

>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; C99 is a bit tighter on this,
but not enough so that a constant +1 would work.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

[Joe Wright]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>ev******@cnam.fr wrote:

>>How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?

No, because there may be trap bits involved. However the number
range designated by INT_MIN and INT_MAX will give you the answer.
For unsigned int all you need is UINT_MAX. These are all defined
in <limits.h>.

Correction: padding bits, not trap bits. (Padding bits may or may not
contribute to trap *representations*.)

Can we simply count the bits?

#include <stdio.h>
int main(void) {
unsigned ui = -1;
int i = 0;
while (ui) {
ui <<= 1;
++i;
}
printf("%d\n", i);
return 0;
}

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

Joe Wright <jo********@comcast.netwrites:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>ev******@cnam.fr wrote:
How can I know the number of bits used for an int value?
Is "sizeof(int) * CHAR_BIT" correct ?
No, because there may be trap bits involved. However the number
range designated by INT_MIN and INT_MAX will give you the
answer. For unsigned int all you need is UINT_MAX. These are all
defined
in <limits.h>.

Correction: padding bits, not trap bits. (Padding bits may or may
not
contribute to trap *representations*.)

Can we simply count the bits?

#include <stdio.h>
int main(void) {
unsigned ui = -1;
int i = 0;
while (ui) {
ui <<= 1;
++i;
}
printf("%d\n", i);
return 0;
}

Sure, but that's O(N) (where N is the number of value bits), and it
doesn't give you a constant expression. If neither of those is a
problem, then counting the bits is certainly a good approach.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Hallvard B Furuseth]

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