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

[Flash Gordon]

Malcolm McLean wrote, On 10/04/07 23:45:

>
"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.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().

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.

Yes we do. At least, it seems to work fine for a lot of us.

When a standard fails it takes down the
system with it. Virtually no C programs are compiled under strictly
conforming ANSI compilers any longer.

Most never have been.

Then we don't want to go the size_t route.

Too late. size_t exists and it is the the type you get from sizeof. If
you don't like it, use another language.

For various reasons it is not
a humanly useable construct,

A number of people manage to use it. Perhaps none of us are human?

and one of two things will happen. Either
it will quietly be dropped and go away,

The first C standard came out in 1989 and since then size_t has not been
dropped, so that shows no sign of happening.

or it will run through C code
wrecking every array index or,

It hasn't wrecked any of mine.

in this case, call to printf,

Which as has been shown is easy to handle. The chances of sizeof being
applied to anything with a size too large for unsigned long are pretty slim.

which in
turn will provoke other changes, and turn the language into something
unrecognisable.

It's not Martin's fault if you have been unable to recognise C since it
was first standardised in 1989. I suspect size_t pre-dates the standard,
but I'm too lazy to check.
--
Flash Gordon

[CBFalconer]

Malcolm McLean wrote:

>

.... snip ...

>
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.

alias cc=*gcc -W -Wall -ansi -pedantic -Wwrite-strings
-Wfloat-equal -gstabs+ -ftrapv -O1 %1&

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

--
Posted via a free Usenet account from http://www.teranews.com

[robertwessel2]

On Apr 10, 6:31 pm, jacob navia <[e-mail] comp.frwrote:

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.

Actually several compilers support 32 bit pointers (at least as an
option), on 64 bit systems. For programs that don't need the extra
address space, and can be loaded in the first 2GB of memory, this can
lead to a significant reduction in memory and cache usage. For
example, the HP Alpha Tru64/Linux C/C++ compiler has the -xtaso_short
option.

[Tim Prince]

broeisi wrote:

>
On 10 apr, 21:07, [e-mail] c-cnrc.gc.ca (Walter Roberson) wrote:

>In article <1176230815.876 762.147...@b75g 2000hsg.googleg roups.com>,

broeisi <broeis...@gmai l.comwrote:

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

No, not in standard C.

First you'd have to define exactly what it means for a processor
to be 32 or 64 bit, which is something that has at least 4 different
correct (but contradictory) answers.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

Thank you very much for you answer Christopher.
But how does an OS like linux or windows know that it's installed on a
computer with a 32 or 64 bit processor?

The most usual distinction is whether a pointer fits in 32 bits. A
32-bit OS installed on a 64-bit processor doesn't care whether the
processor supports 64 bits. A 64-bit OS doesn't have to care either; it
wouldn't be running without its expected form of more-than-32-bit
support. And, a 32-bit C compiler running under the popular 64-bit
systems doesn't care about what is outside the subset of the platform
capabiity that it sees. It is responsible for generating code that
(normally) doesn't care whether it runs under a 32- or 64-bit OS, nor
does it have a way to know the difference without exceeding the bound of
Standard C and this forum.

[Keith Thompson]

Eric Sosman <Er*********@su n.comwrites:
[snip]

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,

Context: The code in question prints the size, in bits, of type int.

has
*anybody* *ever* used a machine where the output would
be "64-bit processor\n"?

Yup.

(An old Cray model, perhaps?)

Yup.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Keith Thompson wrote:

Eric Sosman <Er*********@su n.comwrites:
[snip]

> 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,

Context: The code in question prints the size, in bits, of type int.

> has
*anybody* *ever* used a machine where the output would
be "64-bit processor\n"?

Yup.

> (An old Cray model, perhaps?)

Yup.

Given your location, are any of those beasts still in use?

--
Ian Collins.

[Keith Thompson]

"ro***********@ yahoo.com" <ro***********@ yahoo.comwrites :

On Apr 10, 6:31 pm, jacob navia <[e-mail] comp.frwrote:

>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.

Actually several compilers support 32 bit pointers (at least as an
option), on 64 bit systems. For programs that don't need the extra
address space, and can be loaded in the first 2GB of memory, this can
lead to a significant reduction in memory and cache usage. For
example, the HP Alpha Tru64/Linux C/C++ compiler has the -xtaso_short
option.

One might argue that such a program is running on an emulated 32-bit
system under a 64-bit system.

I agree that CHAR_BIT * sizeof(void*) will capture the "bit-ness" (as
in, 16-bit system vs. 32-bit system vs. 64-bit system) for most, if
not all, systems I've ever seen.

That doesn't, of course, make it meaningful for *all* systems. And
the C standard has no concept of a "32-bit system" or a "64-bit
system".

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Malcolm McLean" <re*******@btin ternet.comwrite s:

"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.

It's undefined by *several* particular standards: C89/C90, C95, C99,
<OT>and however many C++ standards there have been</OT>.

In any case, ignoring everything after K&R1 is magnificently foolish.

sizeof() return an int in K and
R C.

Chapter and verse, please. K&R1, page 188, says:

This expression is semantically an integer constant and may be
used anywhere a constant is required.

I see no indication that this "integer constant" is necessarily of
type int.

You are more likely to break by passing %z to printf().

So convert to unsigned long and use "%lu". Or convert to int and use
"%d". As long as the size does not exceed 32767, the resulting code
is correct under *all* relevant standards, going all the way back to
K&R1 and probably farther.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Keith Thompson wrote:

"ro***********@ yahoo.com" <ro***********@ yahoo.comwrites :

>>On Apr 10, 6:31 pm, jacob navia <[e-mail] comp.frwrote:

>>>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.

Actually several compilers support 32 bit pointers (at least as an
option), on 64 bit systems. For programs that don't need the extra
address space, and can be loaded in the first 2GB of memory, this can
lead to a significant reduction in memory and cache usage. For
example, the HP Alpha Tru64/Linux C/C++ compiler has the -xtaso_short
option.

One might argue that such a program is running on an emulated 32-bit
system under a 64-bit system.

Not in the general case. I don't know about other operating systems,
but Solaris for one runs 32 bit binaries "native" on a 64 bit platform.

--
Ian Collins.

[Walter Roberson]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>"ro*********** @yahoo.com" <ro***********@ yahoo.comwrites :

>Actually several compilers support 32 bit pointers (at least as an
option), on 64 bit systems. For programs that don't need the extra
address space, and can be loaded in the first 2GB of memory, this can
lead to a significant reduction in memory and cache usage.

>One might argue that such a program is running on an emulated 32-bit
system under a 64-bit system.

One might, but then another one might argue that that would be wrong
for SGI IRIX64. There is a control bit in the process status word
that determines whether the processor is running with 32 bit or 64
bit pointers. It isn't an emulation in any traditional sense:
there are different microcode paths, both of which run at full speed.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)