Thread: number of bits supported for int on my machine

I am doing a problem that asks for the number of bits allocated to an integer on my machine. The problem states given the fact that ~0 produces an integer with all zeros, write a program that would indicate how many bits are allocated to an integer. So I wrote this

Code:

#include <stdio.h>
int main (void)
{
int i;
i = 0;
printf ("Here is  ----%o\n", ~i);
}

Here is the output:

Code:

$ 3
Here is  ----37777777777

Given that I am printing this in octal I believe I am looking at 32 bits. Right? I do realize these are two different things, but I am using Win10 and expected 64bits. I even switched compilers to the 64bit version of MinGw but the result is the same. I guess I am trying to figure out which of the following decides the size of the memory allocated to the integer; is it the compiler, OS architecture, of C language?

Originally Posted by zolfaghar

I am doing a problem that asks for the number of bits allocated to an integer on my machine.

Talking about integer is ambiguous. We can have 'short' integer, integer, long integer, long long integer.

I think you're talking about long integer which is typically 64-bits on 64 bit machines.

Also, make sure you're formatting correctly when printing. If you expect a long integer you have to format a long integer otherwise it will be truncated.

Originally Posted by laserlight

~0 results in an integer with all the bits set, not unset. A catch is that the interpretation of the result is different depending on whether the integer is unsigned, signed in two's complement, signed in one's complement, or signed in sign and magnitude representation.


Sure, but the program that you wrote does not correctly match the format specifiers to their corresponding arguments in many cases. For example, gcc 4.8.4 rightly warns:

Code:

test.c: In function ‘main’:
test.c:8:1: warning: format ‘%lo’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat=]
 printf ("Here is number ----%lo\n", ~i);
 ^
test.c:9:1: warning: format ‘%llo’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘int’ [-Wformat=]
 printf ("Here is number ----%llo\n", ~i);
 ^
test.c:10:1: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘int’ [-Wformat=]
 printf ("Here is number ----%llu\n", ~i);
 ^
test.c:13:1: warning: format ‘%llo’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘long int’ [-Wformat=]
 printf ("Here is number ----%llo\n", ~j);
 ^
test.c:14:1: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘long int’ [-Wformat=]
 printf ("Here is number ----%llu\n", ~j);
 ^
test.c:16:1: warning: format ‘%lo’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘long long int’ [-Wformat=]
 printf ("Here is number ----%lo\n", ~k);
 ^

These mismatches technically lead to undefined behaviour. What you can do is to either change the format specifier to match the type of the argument, or cast the arguments so that the type matches the format specifier.

Thanks. I'll fix that.

I'm not sure how every bit set is supposed to help? Maybe looking for something like this?

Code:

    int c;
    unsigned int v = ~0;
    for (c = 0; v > 0; ++c, v &= v - 1) /* void */;

c contains the number of bits.

I don't know why you're using octal. Hex is more common.

Code:

#include <stdio.h>

int main(void) {
    unsigned             i = 0;
    long unsigned       li = 0;
    long long unsigned lli = 0;

    printf("          unsigned: %16x\n",     ~i);
    printf("     long unsigned: %16lx\n",   ~li);
    printf("long long unsigned: %16llx\n", ~lli);

    return 0;
}

/* Ouptut:
          unsigned:         ffffffff
     long unsigned: ffffffffffffffff
long long unsigned: ffffffffffffffff
*/

Originally Posted by whiteflags

I'm not sure how every bit set is supposed to help? Maybe looking for something like this?

Code:

    int c;
    unsigned int v = ~0;
    for (c = 0; v > 0; ++c, v &= v - 1) /* void */;

c contains the number of bits.

Well, in my case, I was wondering why we are not using 'sizeof' ? Am I missing something or should 'sizeof' be enough ?

Code:

#include <stdio.h>


int main (void)
{
    printf ("Here is  ----%d\n", sizeof(long int) * 8);
}

Code:

#include <stdio.h>

// gcc tst.c -o tst

int main()
{
    int i;
    int Sj;
    unsigned int Uj;


    for(Sj=1, i=0; Sj != 0; Sj <<= 1,i++);

    printf("Number of iterations/bits = %d for a signed int\n", i);



    for(Uj=1, i=0; Uj !=0; Uj <<= 1,i++);

    printf("Number of iterations/bits = %d for an unsigned int\n", i);

}

Ah. Thanks. This is what I was wondering about; why it is not 64. Thanks.

Originally Posted by christop

On 64-bit Windows, the "long" type is 32 bits for backward compatibility with a bunch of poorly-written software that assumes "LONG" and "long" are the same type. Granted, Windows APIs are poorly designed for using a 32-bit "LONG" type in the first place.

Virtually every other 64-bit OS has a 64-bit long type because they don't have such backward-compatibility issues.

This was my question; thanks for the answer. I was wondering why even long ints were not allocated 64 bits.

Originally Posted by whiteflags

I'm not sure how every bit set is supposed to help? Maybe looking for something like this?

Code:

    int c;
    unsigned int v = ~0;
    for (c = 0; v > 0; ++c, v &= v - 1) /* void */;

c contains the number of bits.

I should have provided more context. As you may know I switched books, and now I am following "Programming in C" by Stephen Kochan. He mentioned in chapter 11, that different machines allocate different number of bits to an integer, and not to make any assumptions on the number of bits allocated to an unsigned int when attempting one of his problems. I took that, and wanted to understand it even better; that is why I asked the question. I think knowing about these issues and understanding as to why they come up and how to find out about them is important. This is based on my very limited coding skills; I just envision I may run into situations which I need to be aware of such potential mismatches.

By the way thanks to everyone who told me to switch books.