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

[Ian Collins]

Malcolm McLean wrote:

>>

size_t is a change. It is not present in K and R C, and rightly so.

Ah, so you are objecting to C89 now. It's a little late for that.

Another change is not having int as the natural integer type for the
platform.

But 32 bit int is a natural integer type for most contemporary 64 bit
systems.

Whilst there is an argument for having fixed-size types in a
language, C chose the other route. We are now seeing a reversal of
policy so that existing 32-bit code won't break under 64 bits. That is,
badly-written 32-bit code. If it was written properly it wouldn't assume
32 bit ints and longs.

So you are labelling the BSD networking code as bad? The assumption
that long is 32 bits is pretty widespread there.

When ever C hits the real world, developers have added fixed size types.
Now they are standardised. Good.

--
Ian Collins.

[Keith Thompson]

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

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwr ote in message
news:46******** *********@news. xs4all.nl...

>"Malcolm McLean" <re*******@btin ternet.comwrote :

>>The answer is an ssize_t. Which for efficiency reasons is allowed
to fail if
the difference in size_t's spans more than half the address space.

Oh FFS, use ptrdiff_t already! Have you even _read_ the Standard, or are
you just talking out of blithe ignorance? ssize_t is completely
unnecessary, and if you knew C well, you'd know that.

In the example we have two calls to functions yielding size_ts. We
then want the difference, which can be negative. However ptrdiff_t is
not appropriate since the operands are not pointers. ssize_t is
intended for the purpose.

ssize_t is not part of the C standard (it's defined by POSIX). I
wouldn't mind if it were added to standard C. ssize_t, where it
exists, is a signed type the same size as the unsigned type size_t.
ptrdiff_t, though it's not defined that way, is very likely to be a
signed type the same size as size_t, so using it to store the
difference between two size_t values (where the result may be negative
and is unlikely to overflow) is not unreasonable.

If you want to be sure you can avoid overflow (or as sure as it's
possible to be), you can use intmax_t if it's available, or long if
you want to maintain C90 compatibility.

>>The point is that once we admit a fundamental, if subtle, change into
the language,

No, the point is that having different size integers, and size_t for
indices, is _not_ a change. That's how C has been since at least 1989.

size_t is a change. It is not present in K and R C, and rightly
so.

A lot of things aren't in K&R C. Time has passed. size_t was
introduced in the 1989 ANSI standard; the time to complain about it
was about 20 years ago.

Another change is not having int as the natural integer type for
the platform.

That has always been an unenforceable requirement. There is no clear
definition for the phrase "natural integer type for the platform" (or
as the C99 standard says, "the natural size suggested by the
architecture of the execution environment"). And if there were a
clear definition, I seriously doubt that it would involve the size of
the address bus.

Whilst there is an argument for having fixed-size types
in a language, C chose the other route. We are now seeing a reversal
of policy so that existing 32-bit code won't break under 64 bits. That
is, badly-written 32-bit code. If it was written properly it wouldn't
assume 32 bit ints and longs.

The same thing happened during the transition from 16-bit to 32-bit
architectures; there were implementations for 32-bit machines that had
16-bit ints. Somehow we muddled through.

I am arguing for keeping the existing policy that has served C well
for so long. size_t was tolerable as long as no programmer worth his
salt used it. The danger is that the move to 64 bits will encourage or
even force its widespread use.

You are not arguing for leaving C as it is; you are arguing for
changing it to what you want it to be. If you don't like C the way
it's actually defined, that's fine. Arguing that the way you want it
to be is the way it actually is doesn't help your case.

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

[Eric Sosman]

Malcolm McLean wrote On 04/20/07 17:58,:

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwr ote

>>[...]

No, the point is that having different size integers, and size_t for
indices, is _not_ a change. That's how C has been since at least 1989.

size_t is a change. It is not present in K and R C, and rightly so. Another

K&R C also lacked void and void*, long double,
function prototypes, <stdarg.hand variadic functions,
<stdlib.h>, <stddef.h>, offsetof, <limits.h>, ... The
introductions of *all* these things and more were changes.

change is not having int as the natural integer type for the platform.

You keep asserting this, but it was never so. int was
always a "useful" size that "made sense" for the platform.
I've used eight-bit machines with C implementations , but
never have I seen an 8-bit int.

Whilst there is an argument for having fixed-size types in a language, C
chose the other route. We are now seeing a reversal of policy so that
existing 32-bit code won't break under 64 bits. That is, badly-written
32-bit code. If it was written properly it wouldn't assume 32 bit ints and
longs.

Part of the "Spirit of C" is (I'm not making this up;
it's in the Rationale) is "Trust the programmer." It turns
out that some programmers are untrustworthy, which is too
bad -- but the cure isn't to dumb down C, but to smarten up
the bad programmers.

And do you imagine that expanding int to 64 or 128 or
1024 bits will magically fix all that bad code? Then it's
obvious you've had NO experience in porting code to an
environment where the data type sizes change. If you had
any such experience, you wouldn't believe such folderol.

I am arguing for keeping the existing policy that has served C well for so
long.

I am arguing for keeping the existing policy that assigns
colors to all C's fundamental data types. ("But there is no
such policy, and never has been!") Right you are, Jocko,
right you are.

size_t was tolerable as long as no programmer worth his salt used it.
The danger is that the move to 64 bits will encourage or even force its
widespread use.

"It's a poor workman who blames his tools."

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

[Keith Thompson]

Ian Collins <ia******@hotma il.comwrites:

Malcolm McLean wrote:

[...]

>Whilst there is an argument for having fixed-size types in a
language, C chose the other route. We are now seeing a reversal of
policy so that existing 32-bit code won't break under 64 bits. That is,
badly-written 32-bit code. If it was written properly it wouldn't assume
32 bit ints and longs.

So you are labelling the BSD networking code as bad? The assumption
that long is 32 bits is pretty widespread there.

Is it? If so, I'd say that's a bad assumption. I'd be very surprised
if that code isn't already running on systems with 64-bit longs.

When ever C hits the real world, developers have added fixed size types.
Now they are standardised. Good.

Agreed. Though I suspect fixed size types tend to be overused. In
many cases, what you really need is a type able to represent (at
least) some specified range of values. C99's <stdint.h>,
unfortunately IMHO, gave the easy-to-remember names to the exact-width
types rather than the potentially more useful least-width types.

For example:

int_least32_t is the narrowest signed type of at least 32 bits.

int_fast32_t is the "fastest" signed type of at least 32 bits.

int32_t is *exactly* 32 bits wide; if there is no such type,
int32_t doesn't exist.

On a 64-bit CPU, for example, int_least32_t might be 32 bits and
int_fast32_t might be 64 bits.

I think that int32_t, the exact-width type, is really needed only for
conformance to some externally imposed data layout. For internal
numeric calculations, int_fast32_t or int_least32_t is more
appropriate, depending on whether you need large arrays. But since
the name "int32_t" is more obvious, a lot of programmers are going to
use it unnecessarily.

That's probably not *too* bad. If int32_t exists, it's going to be
the same as int_least32_t, and if it doesn't, the code will fail to
compile in a rather obvious manner. (But then the programmer may be
tempted to define his own "int32_t" that's actually 64 bits.)

IMHO, it would have been better to define:

int_least32_t
int_fast32_t
int_exact32_t

or perhaps even to introduce a new syntax for declaring such types
rather than using ad hoc typedefs.

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

Ian Collins <ia******@hotma il.comwrites:

>>Malcolm McLean wrote:

[...]

>>>Whilst there is an argument for having fixed-size types in a
language, C chose the other route. We are now seeing a reversal of
policy so that existing 32-bit code won't break under 64 bits. That is,
badly-written 32-bit code. If it was written properly it wouldn't assume
32 bit ints and longs.

So you are labelling the BSD networking code as bad? The assumption
that long is 32 bits is pretty widespread there.

Is it? If so, I'd say that's a bad assumption. I'd be very surprised
if that code isn't already running on systems with 64-bit longs.

Yes, it has been for a long time, I was referring to the earlier code
where unsigned long is used extensively for 32 bit IP addresses. Even
some for the function names are a give away, ntohl/htonl for instance.

>

>>When ever C hits the real world, developers have added fixed size types.
Now they are standardised. Good.

Agreed. Though I suspect fixed size types tend to be overused. In
many cases, what you really need is a type able to represent (at
least) some specified range of values. C99's <stdint.h>,
unfortunately IMHO, gave the easy-to-remember names to the exact-width
types rather than the potentially more useful least-width types.

Agreed.

--
Ian Collins.

[Malcolm McLean]

"Eric Sosman" <Er*********@su n.comwrote in message
news:1177108464 .140009@news1nw k...

Malcolm McLean wrote On 04/20/07 17:58,:

>change is not having int as the natural integer type for the platform.

You keep asserting this, but it was never so. int was
always a "useful" size that "made sense" for the platform.
I've used eight-bit machines with C implementations , but
never have I seen an 8-bit int.

Your machine had an eight bit address bus?
There is a bit of wooliness in the "natural integer type". However generally
it is the size needed to index the largest possible array, which generally
boils down to the size of the address bus, but not on old x86s because of
the weirdness of the architecture.
On a machine with 64 bits of flat address space and a 64 bit data register
file the natural integer size is quite clearly 64 bits. At the moment there
might be a performace case for using 32-bit integers to conserve cache
space. I've not said that all the good arguments are on my side. However I
suspect that this issue will prove to be quite short-lived.

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

[Ian Collins]

Malcolm McLean wrote:

>
"Eric Sosman" <Er*********@su n.comwrote in message
news:1177108464 .140009@news1nw k...

>Malcolm McLean wrote On 04/20/07 17:58,:

>>change is not having int as the natural integer type for the platform.

You keep asserting this, but it was never so. int was
always a "useful" size that "made sense" for the platform.
I've used eight-bit machines with C implementations , but
never have I seen an 8-bit int.

Your machine had an eight bit address bus?
There is a bit of wooliness in the "natural integer type". However
generally it is the size needed to index the largest possible array,
which generally boils down to the size of the address bus, but not on
old x86s because of the weirdness of the architecture.

No, it can't do that, int is a signed type, so it can never index the
largest possible array.

On a machine with 64 bits of flat address space and a 64 bit data
register file the natural integer size is quite clearly 64 bits. At the
moment there might be a performace case for using 32-bit integers to
conserve cache space. I've not said that all the good arguments are on
my side. However I suspect that this issue will prove to be quite
short-lived.

Considering 64 bit systems have been in widespread use for over a
decade, short is a relative term.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Malcolm McLean wrote:

<snip>

>Whilst there is an argument for having fixed-size types in a
language, C chose the other route. We are now seeing a reversal of
policy so that existing 32-bit code won't break under 64 bits. That
is, badly-written 32-bit code. If it was written properly it wouldn't
assume 32 bit ints and longs.

So you are labelling the BSD networking code as bad? The assumption
that long is 32 bits is pretty widespread there.

To be diplomatic, let us just say that the BSD networking code would
have been *even better* if it didn't make invalid assumptions about
integer type sizes.

When ever C hits the real world, developers have added fixed size
types.
Now they are standardised. Good.

Whenever language designers specify fixed size types, they have to come
back later and specify some more. Bad.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>>When ever C hits the real world, developers have added fixed size
types.
Now they are standardised. Good.

Whenever language designers specify fixed size types, they have to come
back later and specify some more. Bad.

If don't specify the type, everyone else who wants it has to add their
own, so we ended up with typedefs like U8, INT16 and just about every
other possible naming of fixed types. At least the standard now sets a
naming convention.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Ian Collins said:

>>>When ever C hits the real world, developers have added fixed size
types.
Now they are standardised. Good.

Whenever language designers specify fixed size types, they have to
come
back later and specify some more. Bad.

If don't specify the type, everyone else who wants it has to add their
own,

Not quite everyone.

so we ended up with typedefs like U8, INT16 and just about every
other possible naming of fixed types. At least the standard now sets
a naming convention.

Which can safely be ignored, on the whole.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.