32 or 64 bit processor info in C

[broeisi]

Hello,

Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

Cheers,

Broeisi

[Walter Roberson]

In article <ev*********@td i.cu.mi.it>, Army1987 <pl********@for .itwrote:

>"broeisi" <br*******@gmai l.comha scritto nel messaggio
news:11******* *************** @b75g2000hsg.go oglegroups.com. ..

>Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

>Nothing guarantees it to always work, but the standard says "A ''plain'' int
object has the natural size suggested by the architecture of the execution
environment" , so CHAR_BIT*sizeof (int) is likely to do that (and when it
isn't, it is very likely to be more useful than the actual processor bits in
a C program).

I can't think at the moment of any 64 bit systems on which that
would be true. Not saying there aren't any, but they aren't common.
On "64 bit systems", int is commonly 32 bits, and it is usually
long or long long that is 64 bits. (Okay, maybe excepting Crays.)

The fact that a particular processor can -do- 64 bit operations
doesn't mean that those are the "most natural" operations on that
system.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[Martin Ambuhl]

Malcolm McLean wrote:

>
"broeisi" <br*******@gmai l.comwrote in message
news:11******** **************@ b75g2000hsg.goo glegroups.com.. .

>Hello,

Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

Cheers,

int is the natural integer size for the machine. CHAR_BIT gives the
number of bits in a byte.
So printf("%d-bit processor\n", sizeof(int) * CHAR_BIT);
should tell you whether you are dealing with a processor that handles
64-bit values nicely or an inferior machine.

Whether sizeof(int) * CHAR_BIT gives the right answer (among several
possible right answers) aside, the above is just wrong. We have just
covered printing size_t values in the last day:

#include <stdio.h>
#include <limits.h>

int main(void)
{
printf("This printf call has undefined behavior,\n"
"since %%d is for signed ints and sizeof(int) * CHAR_BIT\n"
"is of type size_t, which is unsigned and probably\n"
"larger than an int. If it works without problems, it\n"
"is an accident.\n"
"%d-bit processor\n\n", sizeof(int) * CHAR_BIT);
printf("This printf call is OK, since it uses \"%%zu\" with\n"
"the size_t argument.\n"
"%zu-bit processor\n\n", sizeof(int) * CHAR_BIT);
printf("And this will work where sizeof(int) * CHAR_BIT\n"
"is not larger than ULONG_MAX.\n"
"%lu-bit processor\n\n",
(unsigned long) (sizeof(int) * CHAR_BIT));
return 0;
}

[Eric Sosman]

Malcolm McLean wrote On 04/10/07 16:00,:

"broeisi" <br*******@gmai l.comwrote in message
news:11******** **************@ b75g2000hsg.goo glegroups.com.. .

>>Hello,

Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

Cheers,

int is the natural integer size for the machine. CHAR_BIT gives the number
of bits in a byte.
So printf("%d-bit processor\n", sizeof(int) * CHAR_BIT);
should tell you whether you are dealing with a processor that handles 64-bit
values nicely or an inferior machine.

Martin Ambuhl has already pointed out that there is
no reason to expect any particular output.

But I have a question for the group at large: Once
the code is fixed, either via "%zd" or by casting, has
*anybody* *ever* used a machine where the output would
be "64-bit processor\n"? (An old Cray model, perhaps?)

If not, we must conclude that all extant machines are
inferior, and then the further question arises: inferior
to what?

--
Er*********@sun .com

[Malcolm McLean]

"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58******** *****@mid.indiv idual.net...

Malcolm McLean wrote:

>>
"broeisi" <br*******@gmai l.comwrote in message
news:11******* *************** @b75g2000hsg.go oglegroups.com. ..

>>Hello,

Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

Cheers,

int is the natural integer size for the machine. CHAR_BIT gives the
number of bits in a byte.
So printf("%d-bit processor\n", sizeof(int) * CHAR_BIT);
should tell you whether you are dealing with a processor that handles
64-bit values nicely or an inferior machine.

Whether sizeof(int) * CHAR_BIT gives the right answer (among several
possible right answers) aside, the above is just wrong. We have just
covered printing size_t values in the last day:

#include <stdio.h>
#include <limits.h>

int main(void)
{
printf("This printf call has undefined behavior,\n"
"since %%d is for signed ints and sizeof(int) * CHAR_BIT\n"
"is of type size_t, which is unsigned and probably\n"
"larger than an int. If it works without problems, it\n"
"is an accident.\n"
"%d-bit processor\n\n", sizeof(int) * CHAR_BIT);
printf("This printf call is OK, since it uses \"%%zu\" with\n"
"the size_t argument.\n"
"%zu-bit processor\n\n", sizeof(int) * CHAR_BIT);
printf("And this will work where sizeof(int) * CHAR_BIT\n"
"is not larger than ULONG_MAX.\n"
"%lu-bit processor\n\n",
(unsigned long) (sizeof(int) * CHAR_BIT));
return 0;
}

See the sort of mess you get into when you allow size_t into your standard?
Actually the %z specifier is less portable and will break on several real
platforms.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Martin Ambuhl]

broeisi wrote:

I think that the answer given by Malcolm is a good one.

The answer given by Malcom is wrong, broken, and involves undefined
behavior. You don't need to thank people for lying to you.

[Malcolm McLean]

"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58******** *****@mid.indiv idual.net...

broeisi wrote:

>I think that the answer given by Malcolm is a good one.

The answer given by Malcom is wrong, broken, and involves undefined
behavior. You don't need to thank people for lying to you.

Undefined by one particular standard. sizeof() return an int in K and R C.
You are more likely to break by passing %z to printf().

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Martin Ambuhl]

Malcolm McLean wrote:

>
"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58******** *****@mid.indiv idual.net...

>broeisi wrote:

>>I think that the answer given by Malcolm is a good one.

The answer given by Malcom is wrong, broken, and involves undefined
behavior. You don't need to thank people for lying to you.

Undefined by one particular standard. sizeof() return an int in K and R
C. You are more likely to break by passing %z to printf().

He never gives up, does he. Malcolm, you are wrong. If he has a C90
compiler, he can always use "%lu" and cast to (unsigned long). That was
included in my answer. And "%x" is not a complete specifier. Did you
not bother with reading my answer before twice defending telling an
unsuspecting new programmer to use a broken construct. If you are using
a pre-C89 K&R compiler, that's your problem. Some day you might start
using a defined version of C.

[Ian Collins]

Malcolm McLean wrote:

>
"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58******** *****@mid.indiv idual.net...

>broeisi wrote:

>>I think that the answer given by Malcolm is a good one.

The answer given by Malcom is wrong, broken, and involves undefined
behavior. You don't need to thank people for lying to you.

Undefined by one particular standard. sizeof() return an int in K and R
C. You are more likely to break by passing %z to printf().

Leaving that detail aside, the answer is still wrong. Can you name a
widely used "64 bit" system where sizeof(int) * CHAR_BIT equals 64?

--
Ian Collins.

[Eric Sosman]

Malcolm McLean wrote On 04/10/07 17:32,:

"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58******** *****@mid.indiv idual.net...

>>broeisi wrote:

>>>I think that the answer given by Malcolm is a good one.

The answer given by Malcom is wrong, broken, and involves undefined
behavior. You don't need to thank people for lying to you.

Undefined by one particular standard. sizeof() return an int in K and R C.
You are more likely to break by passing %z to printf().

Out of curiosity, what would that "one particular
standard" be? Does it claim to define anything, and
if so, what? Has it achieved any noticeable level of
support from ISO, ANSI, or other standards bodies?

Most important: Is that "one particular standard,"
by any stretch of imagination, on-topic for c.l.c.?

--
Er*********@sun .com

[Malcolm McLean]

"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58******** *****@mid.indiv idual.net...

Malcolm McLean wrote:

>>
"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58******* ******@mid.indi vidual.net...

>>broeisi wrote:

I think that the answer given by Malcolm is a good one.

The answer given by Malcom is wrong, broken, and involves undefined
behavior. You don't need to thank people for lying to you.

Undefined by one particular standard. sizeof() return an int in K and R
C. You are more likely to break by passing %z to printf().

He never gives up, does he. Malcolm, you are wrong. If he has a C90
compiler, he can always use "%lu" and cast to (unsigned long). That was
included in my answer. And "%x" is not a complete specifier. Did you not
bother with reading my answer before twice defending telling an
unsuspecting new programmer to use a broken construct. If you are using a
pre-C89 K&R compiler, that's your problem. Some day you might start using
a defined version of C.

We no longer have a standard. When a standard fails it takes down the system
with it. Virtually no C programs are compiled under strictly conforming ANSI
compilers any longer.
Then we don't want to go the size_t route. For various reasons it is not a
humanly useable construct, and one of two things will happen. Either it will
quietly be dropped and go away, or it will run through C code wrecking every
array index or, in this case, call to printf, which in turn will provoke
other changes, and turn the language into something unrecognisable.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm