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

[jacob navia]

Ian Collins a écrit :

Malcolm McLean wrote:

>>"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58****** *******@mid.ind ividual.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?

Neither SPARC 64 bits, nor Linux 64 bit nor WIndows 64 have an int
of 64 bits.

It would have been better to use "long", but that fails in
windows 64/Vista 64 since long is 32 bits in those systems.

[Malcolm McLean]

"jacob navia" <ja***@jacob.re mcomp.frwrote in message
news:46******** **************@ news.orange.fr. ..

Ian Collins a écrit :

>Malcolm McLean wrote:

>>>"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58***** ********@mid.in dividual.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?

Neither SPARC 64 bits, nor Linux 64 bit nor WIndows 64 have an int
of 64 bits.

It would have been better to use "long", but that fails in
windows 64/Vista 64 since long is 32 bits in those systems.

I know. Most systems are not conforming. Lack of 64 bit ints also has the
potential to wreck our beloved C language. Soon it will be necessary to use
a gibberish type every time you need an integer, and cast to another
gibberish type to pass to a library function.

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

[jacob navia]

broeisi a écrit :

Hello,

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

Cheers,

Broeisi

Tbe processor in the machine that I use to write this message
can transform itself from

o 16 bit processor (at startup)
o 32 bit processor (If I boot into Windows XP or linux 32)
o 64 bit processor (If I boot into Vista 64 or linux 64)

All those systems use EXACTLY THE SAME HARDWARE!

If the processor runs under a 32 bit system there is NO
WAY (unless you use assembly) to know that processor can be
64 bits.

For x86 systems the only way to know the kind of processor
you are running on is to issue the CPUID assembly instruction.

lcc-win32 has an "intrinsic" function (called cpuid() )
that will return you a structure with several bit fields that
specify the type of processor, etc. But this must be done
in a machine specific way. Other processors may support different
instructions and return values for similar instructions.

But this can't be done at all from C. Actually C is designed
to ABSTRACT from those details and make your programs run the
same in different machines by emulating missing features. That is why
you can use 64 bit integers (or even 128 ones) in a 32 bit system.

C will emulate the missing functionality for you, masking the
differences in hardware. This makes programs written in C portable
from a machine to the next.

[Ian Collins]

jacob navia wrote:

Ian Collins a écrit :

>Malcolm McLean wrote:

>>"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58****** *******@mid.ind ividual.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?

Neither SPARC 64 bits, nor Linux 64 bit nor WIndows 64 have an int
of 64 bits.

It would have been better to use "long", but that fails in
windows 64/Vista 64 since long is 32 bits in those systems.

Better still void*. But still not a 100% solution.

--
Ian Collins.

[Ian Collins]

Malcolm McLean wrote:

>
"jacob navia" <ja***@jacob.re mcomp.frwrote in message
news:46******** **************@ news.orange.fr. ..

>Ian Collins a écrit :

>>Malcolm McLean wrote:

"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58***** ********@mid.in dividual.net...
>
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?

Neither SPARC 64 bits, nor Linux 64 bit nor WIndows 64 have an int
of 64 bits.

It would have been better to use "long", but that fails in
windows 64/Vista 64 since long is 32 bits in those systems.

I know. Most systems are not conforming. Lack of 64 bit ints also has
the potential to wreck our beloved C language. Soon it will be necessary
to use a gibberish type every time you need an integer, and cast to
another gibberish type to pass to a library function.

Non-conforming to what?

At least with most sensible 64 bit models we now have sizeof(sort) <
sizeof(int) < sizeof(long).

I've no idea where the notion of "gibberish type" comes into this.

--
Ian Collins.

[jacob navia]

Ian Collins a écrit :

>
Better still void*. But still not a 100% solution.

WOW, after all those pointless discussions you bring about a true
solution!!!

Why would be that wrong?

I can't imagine a 64 bit system where pointers are 32 bits.

It would fail only in 16 bit systems with 32 bit pointers...
like MSDOS, for instance.

In system mode, some 32 bit processors (x86) use 48 bit pointers
(with 16+32 segmented model pointers). But none of those constructs
are visible in user mode, as far as I know.

[Ian Collins]

jacob navia wrote:

Ian Collins a écrit :

>>
Better still void*. But still not a 100% solution.

WOW, after all those pointless discussions you bring about a true
solution!!!

Why would be that wrong?

It's undoubtedly wrong on a DS9000 and probably wrong on a number of
Harvard architecture machines. This being clc, one has to minimise the
opportunities for the smart arses!

--
Ian Collins.

[Gordon Burditt]

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

>or 64 bit?

I doubt very much whether you can get a consistent answer for this
even if you use two armies of lawyers, a billion dollars, and 10
years of lawsuits. There are many different, and conflicting
definitions for what bittedness a processor is.

[Ian Collins]

Gordon Burditt wrote:

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

I doubt very much whether you can get a consistent answer for this
even if you use two armies of lawyers, a billion dollars, and 10
years of lawsuits. There are many different, and conflicting
definitions for what bittedness a processor is.

Who asked the question?

--
Ian Collins.

[Old Wolf]

On Apr 11, 10:45 am, "Malcolm McLean" <regniz...@btin ternet.com>
wrote:

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.

There's no such thing as a 'strictly conforming' compiler. Compilers
conform. Programs either conform, or conform strictly. (Or neither).

And yes, many people do in fact write conforming code and compile it
with conforming compilers.

Then we don't want to go the size_t route. For various reasons it is not a
humanly useable construct,

Except by the millions of humans who use it, one presumes.