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 <11**********************@b75g2000hsg.googlegroups .com>,
broeisi <br*******@gmail.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

[broeisi]

On 10 apr, 21:07, [e-mail] (Walter Roberson) wrote:

In article <[e-mail] .com>,

broeisi <[e-mail]:

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?

[Walter Roberson]

In article <11**********************@b75g2000hsg.googlegroups .com>,
broeisi <br*******@gmail.comwrote:

>On 10 apr, 21:07, [e-mail] (Walter Roberson) wrote:

>In article <[e-mail] .com>,

>broeisi <[e-mail]:

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

>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 OS is implementation, and so is allowed to do things that
C leaves undefined or unspecified.

When an OS is compiled, it already has certain hardware assumptions
built into it -- assumptions such as what the machine language of
the processor looks like. OSes may have access to processor status
registers that C does not define; the status registers may even
require special instructions to access. Since the OS knows what
kind of processor (generally) it is running on, it knows how to
interpret the status registers to determine processor capabilities
(such as whether there is hardware audio support instructions.)

Some people define "32 or 64 bit processor" according to the
instructions that are supported. That's not the best of definitions,
though, because you also need to know things like how many data
bits may be transfered at a time on the databus: a particular
processor model might support several different databus widths
and hide all the details from the users. A processor might
have an instruction to multiply two 32 bit numbers and produce
a 64 bit number, but it might transfer those 64 bits to memory
16 bits at a time. Do you define "32 or 64 bit" by the instruction
set, or do you define it by what the hardware actually does?
Note: generally, the processor reads some cpu pins hardwired on the
motherboard in order to figure out bus widths.

The C language itself provides no mechanisms to access hardware
directly, and provides almost no restrictions on how the
hardware operates. The C langauge standard provide user facilities
to write -portable- code, and leaves the details of the portable
facilties to the implementation. If you have something that
depends on whether the processor is 32 or 64 bit (whatever that
might mean), then you have something that is almost certainly
not portable C.
--
Programming is what happens while you're busy making other plans.

[Doug]

On 10 Apr, 20:23, "broeisi" <[e-mail]:

<snip>

But how does an OS like linux or windows know that it's installed on a
computer with a 32 or 64 bit processor?

Normally you tell this sort of information when you compile it. So
you'll compile different binaries for 32 bit and 64 bit.

This is an operating system, though. *Usually*, a well-written app
doesn't really need to know whether it's running on 32 or 64 bit.

Hope that helps,
Doug

[Malcolm McLean]

"broeisi" <br*******@gmail.comwrote in message
news:11**********************@b75g2000hsg.googlegr oups.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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Flash Gordon]

broeisi wrote, On 10/04/07 19:46:

Hello,

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

Is that really what you want to know? Depending on what your real
problem is a combination of the information in limits.h and the result
of the sizeof operator should help.
--
Flash Gordon

[Army1987]

"broeisi" <br*******@gmail.comha scritto nel messaggio
news:11**********************@b75g2000hsg.googlegr oups.com...

Hello,

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

[broeisi]

On 10 apr, 21:07, [e-mail] (Walter Roberson) wrote:

In article <[e-mail] .com>,

broeisi <[e-mail]:

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?

[Walter Roberson]

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

>"broeisi" <br*******@gmail.comha scritto nel messaggio
news:11**********************@b75g2000hsg.googleg roups.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

[broeisi]

On 10 apr, 21:30, Flash Gordon <[e-mail]:

broeisi wrote, On 10/04/07 19:46:

Hello,

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

Is that really what you want to know? Depending on what your real
problem is a combination of the information in limits.h and the result
of the sizeof operator should help.
--
Flash Gordon

Flash Gordon,

Yes, that's really what I want to know.
Just trying to learn C by writing lots of silly little programs that
make sense to me..

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

Thanks you all for your answers....

Cheers,

Broeisi

[Martin Ambuhl]

Malcolm McLean wrote:

>
"broeisi" <br*******@gmail.comwrote in message
news:11**********************@b75g2000hsg.googlegr oups.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*******@gmail.comwrote in message
news:11**********************@b75g2000hsg.googlegr oups.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*****@earthlink.netwrote in message
news:58*************@mid.individual.net...

Malcolm McLean wrote:

>>
"broeisi" <br*******@gmail.comwrote in message
news:11**********************@b75g2000hsg.googleg roups.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*****@earthlink.netwrote in message
news:58*************@mid.individual.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*****@earthlink.netwrote in message
news:58*************@mid.individual.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*****@earthlink.netwrote in message
news:58*************@mid.individual.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*****@earthlink.netwrote in message
news:58*************@mid.individual.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*****@earthlink.netwrote in message
news:58*************@mid.individual.net...

Malcolm McLean wrote:

>>
"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:58*************@mid.individual.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

[jacob navia]

Ian Collins a écrit :

Malcolm McLean wrote:

>>"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:58*************@mid.individual.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.remcomp.frwrote in message
news:46**********************@news.orange.fr...

Ian Collins a écrit :

>Malcolm McLean wrote:

>>>"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:58*************@mid.individual.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*****@earthlink.netwrote in message
news:58*************@mid.individual.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.remcomp.frwrote in message
news:46**********************@news.orange.fr...

>Ian Collins a écrit :

>>Malcolm McLean wrote:

"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:58*************@mid.individual.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" <[e-mail]>
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.

[Flash Gordon]

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

>
"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:58*************@mid.individual.net...

>Malcolm McLean wrote:

>>>
"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:58*************@mid.individual.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.securityfocus.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]:

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] (Walter Roberson) wrote:

>In article <[e-mail] .com>,

broeisi <[e-mail]:

>>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*********@sun.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_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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Keith Thompson wrote:

Eric Sosman <Er*********@sun.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]:

>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_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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:58*************@mid.individual.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_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."
-- 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]:

>>>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.org>,
Keith Thompson <ks***@mib.orgwrote:

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

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

Keith Thompson wrote:

>Eric Sosman <Er*********@sun.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?

<OT>Not here at SDSC, no. (I miss the old Cray T90 with its
"waterfall" of Flourinert coolant behind a transparent panel.)</OT>

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[robertwessel2]

On Apr 10, 9:56 pm, Keith Thompson <[e-mail]:

"[e-mail]" <[e-mail]:

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.

No, this is different than running a 32 bit binary on a 64 bit system
(which many systems can do, of course). This is basically a native 64
bit executable that happens to store only the low halves of pointers
(with appropriate tweaks to ensure it's never loaded or allocated
memory above 4GB). The executable still calls the normal 64 bit OS
API (and other) functions, widening pointers as needed.

[Stephen Sprunk]

"Eric Sosman" <Er*********@sun.comwrote in message
news:1176237613.873475@news1nwk...

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?)

Didn't Alphas have a 64-bit int?

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[Jean-Marc Bourguet]

"Stephen Sprunk" <st*****@sprunk.orgwrites:

"Eric Sosman" <Er*********@sun.comwrote in message
news:1176237613.873475@news1nwk...

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?)

Didn't Alphas have a 64-bit int?

I've access to an Alpha machine running NetBSD and it has 32 bits int and
64 bits long. Obviously other OS can do something other -- and compilation
flags may also play a roll. I seem to remember that Unix recommands the
LP64 model.

Yours,

--
Jean-Marc

[Chris Dollin]

broeisi wrote:

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

Not portably. Why do you want to know (ie what is it you're trying to do)?

--
The second Jena user conference! http://hpl.hp.com/conferences/juc2007/
"- born in the lab under strict supervision -", - Magenta, /Genetesis/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Keith Thompson]

"Stephen Sprunk" <st*****@sprunk.orgwrites:

"Eric Sosman" <Er*********@sun.comwrote in message
news:1176237613.873475@news1nwk...

> 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?)

Didn't Alphas have a 64-bit int?

It depends on the C implementation. On Alpha systems I've used
running DEC OSF (well, HP OSF, I guess), int is 32 bits and long is 64
bits. On a Cray T3E, which also used Alpha CPUs, int and long are
both 64 bits. (char is 8 bits, and short is 32 bits; the lack of any
16-bit integer type causes problems porting some software.)

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

Keith Thompson wrote:

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

I didn't say one would *win* the argument. Obviously that "one" guy
doesn't know what he's talking about. I'm glad *I* didn't make such a
silly claim.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

broeisi wrote:

On 10 apr, 21:30, Flash Gordon <[e-mail]:

>broeisi wrote, On 10/04/07 19:46:

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

Is that really what you want to know? Depending on what your real
problem is a combination of the information in limits.h and the result
of the sizeof operator should help.
--
Flash Gordon

Flash Gordon,

Yes, that's really what I want to know.
Just trying to learn C by writing lots of silly little programs that
make sense to me..

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

It follows that you haven't learned much.

Yes, that's a smart-ass remark. But it's also an
entirely serious remark: Malcolm has given an "answer"
that is faulty in both conception and execution. If you
consider his answer "good," you have much yet to learn.

A suggestion: If you are interested in learning C,
you will do better to concentrate on *C* and ignore the
ill-defined side-issues. As Malcolm's sad case shows us,
pursuing such matters can lead one so far afield that one
loses the ability to tell C from "C-ish" and winds up making
a fool of oneself in public.

Take this thread's question, for example: What will your
program do differently if it discovers that it is running on
a "64-bit processor" or a "32-bit processor," or for that
matter on an "8-bit processor" or an "18-bit processor?" That
is, what use would your program make of the answer to the
question?

Perhaps you ask whether you have a "64-bit processor" in
order to decide whether you can use a 64-bit `long' or allocate
a forty-gigabyte region with malloc(). If that's the goal, you
are asking the wrong question! If you want to know the range
of `long', use the LONG_MIN and LONG_MAX macros. If you want
to allocate forty gigabytes, first check SIZE_MAX or `(size_t)-1'
and then attempt the allocation. In short, ask the question whose
answer you will actually use, not some other question from which
you imagine you might deduce the answer.

Be direct, don't be circuitous, and DON'T be tricky.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Eric Sosman]

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?

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

64-bit SPARC running a 32-bit program.

--
Eric Sosman
es*****@acm-dot-org.invalid

[jacob navia]

Eric Sosman a écrit :

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?

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

64-bit SPARC running a 32-bit program.

Obvious, but as far as that program is concerned the processor *is* 32 bits!