C Primitive Data Type Sizes

[Kip]

Greetings everyone,

Is there anyone here who could point me to a page or pdf that has a
list of the sizes of all of the C primitive data types on various
implementations such as SPARC, x86, PowerPC, etc?

Thank you.

 

[Walter Roberson]

Is there anyone here who could point me to a page or pdf that has a
list of the sizes of all of the C primitive data types on various
implementations such as SPARC, x86, PowerPC, etc?

You listed chips, but C primitive types can be (and often
have been) implimented in library code.

The size of C primitive types is dependant on the compiler...
which usually takes hints from the underlying hardware, but is
not bound by it.

 

[Kip]

You listed chips, but C primitive types can be (and often
have been) implimented in library code.

The size of C primitive types is dependant on the compiler...
which usually takes hints from the underlying hardware, but is
not bound by it.

Thanks. But it still begs the question of whether or not anyone here
could point me to a page or pdf that has a list of the sizes on all of
the C primitive data types on various implementations?

 

[James McIninch]

<posted & mailed>

No. The sizes are dependent not only on the processor, but also the
operating environment and, in some cases, the compiler used. Consult the
compiler documentation for each that you are interested in.

 

[Me]

Is there anyone here who could point me to a page or pdf that has a

list of the sizes of all of the C primitive data types on various
implementations such as SPARC, x86, PowerPC, etc?

The answer to your question is probably meaningless for what you're
trying to determine anyway (other than knowing about the data types of
existing C implementations, which is a bad question to ask IMHO).
Knowing the size of primitive data types tells you nothing about them
except how much space they take up in relation to a char. It doesn't
tell you anything about how many padding bits a type has, what encoding
it uses for signed integers, alignment requirements, bit ordering, trap
representations, etc. And an implementation of C doesn't depend on the
underlying hardware, it depends on the C compiler and whatever possible
modes it supports. It's entirely possible for it to emulate 9-bit chars
on an 8-bit machine for example. Why would it do something like that?
Well because it's free to do so and it helps debug non-portable
assumptions about C for those of us that prefer to write code according
to what the standard guarantees a conforming implementation must
support.

 

[Lawrence Kirby]

On Mon, 04 Jul 2005 23:58:28 +0000, Kip wrote:

....

Thanks. But it still begs the question of whether or not anyone here
could point me to a page or pdf that has a list of the sizes on all of
the C primitive data types on various implementations?

I don't know of such a list offhand. I'm curious to know however what you
would use such a list for if you find one.

Lawrence

 

[Chris Hills]

Thanks. But it still begs the question of whether or not anyone here
could point me to a page or pdf that has a list of the sizes on all of
the C primitive data types on various implementations?

I doubt such a list exists.

start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there
the problem is that there are very many architectures still in use if
not common.

type pdp11 vax 68000 Cray-2 Unisys Harris 80386
series family 1100 H800

char 8 8 8 8 9 8 8
short 8 8/16 16/16 64(32) 18 24 8/16
int 16 16/32 16/32 64(32) 36 24 16/32
long 32 32 32 64 36 48 32
char * 16 32 32 64 72 24 16/32/48
int * 16 32 32 64(24) 72 24 16/32/64
int (*) 16 32 32 64 56 24 16/32/64




This list is not exhaustive by a LONG LONG way. :-(

 

[Walter Roberson]

I doubt such a list exists.

start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there

Though fortunately char sizes smaller than 8 are not compatible with
the standards, so we do not have to worry about those cases when dealing
with standard C. (One might have to worry about them if one is
writing for a version of C adapted for a specialized processor.)

the problem is that there are very many architectures still in use if
not common.

And the answer can depend on how one compiles...

type pdp11 vax 68000 Cray-2 Unisys Harris 80386
series family 1100 H800

I hope that examing this table of one signal OS's processor family
will convince Kip that in listing major chips lines, he is asking the
wrong question.


SGI, MIPS chips, compiled with SGI's cc compilers in -coff mode
char 8, short 16, int 32, long 32, char * 32, int * 32, int (*) 32

R2000 - IRIX 2, IRIX 3.1, IRIX 3.2
R3000 - IRIX 3.2, IRIX 3.3, IRIX 4.*, IRIX 5.*
R4000 - IRIX 4.0.3 - IRIX 5.*
R4400 - IRIX 5.3
R4600PC - IRIX 5.2 for Indy R4600PC & Challenge S, IRIX 5.3
R4600SC - IRIX 5.2 for Indy R4600SC/XZ & Presenter, IRIX 5.3
R5000 - IRIX 5.3
R8000 - IRIX 6.0, IRIX 6.1
R10000 - not supported
R12000 - not supported
R14000 - not supported


SGI, MIPS chips, compiled with SGI's cc compilers in -o32 mode or -n32 mode
char 8, short 16, int 32, long 32, char * 32, int * 32, int (*) 32
(Note: -o32 mode does not support any 64 bit system calls such as stat64()
or lseek64(), and file sizes are limited to 2 GB. -n32 mode does not
have these restrictions.)

R2000 - not supported
R3000 - not supported
R4000 - IRIX 6.2*, IRIX 6.5 - IRIX 6.5.13-ish
R4400 - IRIX 6.2*, IRIX 6.5 - IRIX 6.5.22
R4600PC - IRIX 6.2*, IRIX 6.5 - IRIX 6.5.?
R4600SC - IRIX 6.2*, IRIX 6.5 - IRIX 6.5.?
R5000 - IRIX 5.3 for R5000 Indy, IRIX 5.3 Indy R5000 with XFS, IRIX 6.2,
IRIX 6.3, IRIX 6.5 - IRIX 6.5.22
R8000 - IRIX 6.0*, IRIX 6.1, IRIX 6.5
R10000 - IRIX 6.2, IRIX 6.5.*
R12000 - early IRIX 6.5.* onward
R14000 - somewhere near IRIX 6.5.17 onward
R16000 - somewhere near IRIX 6.5.23 onward


SGI, MIPS chips, compiled with SGI's cc compilers in -64 mode
char 8, short 16, int 32, long 64, char * 64, int * 64, int (*) 64

R2000 - not supported
R3000 - not supported
R4000 - not supported.
Note: the R4000 has full support for 64 bit arithmetic, and was
-designed- to support 64 bit pointers, but it had a bug in the chip mask
that made 64 bit pointers impractical.
R4400 - IRIX 6.2, IRIX 6.5 - IRIX 6.5.22
R4600PC - not supported
R4600SC - not supported
R5000 - not supported
R8000 - IRIX 6.1, IRIX 6.5 - IRIX 6.5.22
R10000 - IRIX 6.2, IRIX 6.4, IRIX 6.5*
R12000 - early IRIX 6.5.* onward
R14000 - somewhere near IRIX 6.5.17 onward
R16000 - somewhere near IRIX 6.5.23 onward

 

[Chris Croughton]

start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there

Er, char can only be 8 bits or more (at least in standard C). But my
favourite implementation of the DS9000 has char as 11 bits:

sizeof short 2
sizeof int 3
sizeof long 5
sizeof long long 7

the problem is that there are very many architectures still in use if
not common.

type pdp11 vax 68000 Cray-2 Unisys Harris 80386
series family 1100 H800

char 8 8 8 8 9 8 8
short 8 8/16 16/16 64(32) 18 24 8/16

8 bit short is not allowed by the standard.

int 16 16/32 16/32 64(32) 36 24 16/32
long 32 32 32 64 36 48 32
char * 16 32 32 64 72 24 16/32/48

Which 80386 compiler has 48 bit char pointers? Just curious...

int * 16 32 32 64(24) 72 24 16/32/64
int (*) 16 32 32 64 56 24 16/32/64

This list is not exhaustive by a LONG LONG way. :-(

Or even a long double way <g>...

Chris C

 

[Gordon Burditt]

type pdp11 vax 68000 Cray-2 Unisys Harris 80386

Which 80386 compiler has 48 bit char pointers? Just curious...

Any large-model 32-bit-mode i*86 compiler would need this, so you're
not limited to only 4GB code or only 4GB data (the pointer includes
the segment register, for a total of 48 bits). As to whether there
actually are any on the market, I'm not sure.

Gordon L. Burditt

 

[Chris Hills]

Er, char can only be 8 bits or more (at least in standard C).

The OP was asking about IMPLEMENTATIONS.... This is not comp.lang.std.c
To be fair most of the machines with "odd" size chars are rather old and
not common.

But my
favourite implementation of the DS9000 has char as 11 bits:

sizeof short 2
sizeof int 3
sizeof long 5
sizeof long long 7


8 bit short is not allowed by the standard.

The OP asked for a set of primitive data types used on various
implementations. The C standard is only a starting point. The OP was
asking for Reality.

Which 80386 compiler has 48 bit char pointers? Just curious...

It has segment address in it.

Or even a long double way <g>...

Chris C

 

[Kip]

The OP was asking about IMPLEMENTATIONS.... This is not
comp.lang.std.c To be fair most of the machines with "odd" size chars
are rather old and not common.


The OP asked for a set of primitive data types used on various
implementations. The C standard is only a starting point. The OP was
asking for Reality.


It has segment address in it.

lol, thanks Chris

 

[S.Tobias]

The OP was asking about IMPLEMENTATIONS....

He asked about C primitive types.

This is not comp.lang.std.c

No, it's definitely not comp.lang.std.c. It's not comp.std.c either.

This list is present in one of the versions of "Indian Hill C".

 

[Chris Croughton]

The OP was asking about IMPLEMENTATIONS.... This is not comp.lang.std.c
To be fair most of the machines with "odd" size chars are rather old and
not common.

No C implementation can have char with less than 8 bits. There may be
implementations of some language which looks vaguely like C which do
that, but they are not C implementations.

The OP asked for a set of primitive data types used on various
implementations. The C standard is only a starting point. The OP was
asking for Reality.

And in Reality there are no C implementations with short less than 16
bits. There may be implementations of some language which looks vaguely
like C which do that, but they are not C implementations.

It has segment address in it.

As I asked, which 80386 C compiler does that? All the ones I've seen
either operated in 16 bit segment + 16 bit offset mode (usually with a
non-C 'far' qualifier) or in linear address mode with only 32 bits. (If
it needs a special qualifier such as 'far' then it is not C nor is it a
"primitive data type".)

Chris C

 

[Chris Hills]

No C implementation can have char with less than 8 bits. There may be
implementations of some language which looks vaguely like C which do
that, but they are not C implementations.


And in Reality there are no C implementations with short less than 16
bits. There may be implementations of some language which looks vaguely
like C which do that, but they are not C implementations.

There is always some comedian that brings up this bollox. They have a
supercilious and self righteous view of the world. By this sort of
criteria there are no C compiler suites in the world and C is a minority
language.

In reality there are many deviations from ISO-C.... by which I mean C90
and not C99. Most compilers manage C90+ bits and pieces but there are no
complete C99 compiler systems in the world. I know of one but this has a
very small market share and uses a library from another source.

So you can either take the Croughton Theoretical View In which case the
answer to the OP is that are NO implementations of [ISO-] C [9899:1999]
in use OR take the realistic view of what actually happens in the real
world implementations in which case some "C" systems do use 8 bit
shorts and emuns.

The OP was talking about IMPLEMENTATIONS ie the real world tools that
talk t the real world hardware.

this is why newly qualified graduates are usually considered dangerous
when they enter the work place. They know the theory but have yet to
learn the harsh realities of life.

Some C compilers do have 8 bit shorts and enums.

 

[Chris Croughton]

There is always some comedian that brings up this bollox. They have a
supercilious and self righteous view of the world. By this sort of
criteria there are no C compiler suites in the world and C is a minority
language.

Wrong. There are plenty of compilers which manage to implement C90.
Some of them also implement other languages (one popular one, for
instance, also implements C++, Objective C and by default a bastard
C90/C99 with non-standard extensions).

In reality there are many deviations from ISO-C.... by which I mean C90
and not C99. Most compilers manage C90+ bits and pieces but there are no
complete C99 compiler systems in the world. I know of one but this has a
very small market share and uses a library from another source.

Did you read what you wrote? "...there are no complete C99 compiler
systems in the world. I know of one". Either there are none or there is
one (or more), which is it? I've heard of at least one (it's a
front-end to several other compilers). Whether the same people produced
the library or not is irrelevant, no one person writes any major
compiler these days.

So you can either take the Croughton Theoretical View In which case the
answer to the OP is that are NO implementations of [ISO-] C [9899:1999]
in use OR take the realistic view of what actually happens in the real
world implementations in which case some "C" systems do use 8 bit
shorts and emuns.

There is at least one validated implementation of C99 (INCITS/ISO/IEC
9899:1999) compiler, and at least one implementation of the library.

No implementation of C90 or C99 uses 8 bit short (they can use 8 bit
enum if they like - para 6.7.2.2(4) says that "Each enumerated type
shall be compatible with char, a signed integer type, or an
unsigned integer type").

The OP was talking about IMPLEMENTATIONS ie the real world tools that
talk t the real world hardware.

Yes, if it is an implementation of C then it will have short as at least
16 bits and char as at least 8 bits. There are plenty in the real
world, talking to real hardware.

Some C compilers do have 8 bit shorts and enums.

No, they don't. They are compilers of some language like C, but not C
compilers. Of course some manufacturers may call them "C compilers",
but that's the problem with gullible customers (perhaps those graduates
you mentioned) who are willing to buy something when they don't know
what it's supposed to do. Unfortunately the Trade Descriptions and Sale
Of Goods acts don't generally get applied to software.

Chris C

 

[Chris Torek]

The OP was asking about IMPLEMENTATIONS.... This is not comp.lang.std.c

Sure it is.

"It's *spelled* Raymond Luxury Yacht, but it's *pronounced*
Throat-Wobbler Mangrove!"




All PDP-11 implementations always had 16-bit "short"s. All VAX
implementations also always had 16-bit "short"s.

The only C compilers I ever saw with fewer than 16 bits for
"short" predated the 1989 C standard, and were for 8080 and Z80
and similarly, ah, ALU-deficient CPUs.

 

[CBFalconer]

As I asked, which 80386 C compiler does that? All the ones I've
seen either operated in 16 bit segment + 16 bit offset mode
(usually with a non-C 'far' qualifier) or in linear address mode
with only 32 bits. (If it needs a special qualifier such as 'far'
then it is not C nor is it a "primitive data type".)

The so-called linear addressing x86s are really using underlying
segment registers all set to point to the same large segment. I'm
not sure whether those segment registers have 16 or 32 (or
something else) content, and I'm not about to bother checking. At
any rate they control access to segment tables, that have such
things as segment limits and access allowances recorded. So every
'386 up compiler already uses a minimum of 48 bits for a pointer,
it just uses a common value for the part past the first 32 bits.

 

[Chris Croughton]

The so-called linear addressing x86s are really using underlying
segment registers all set to point to the same large segment. I'm
not sure whether those segment registers have 16 or 32 (or
something else) content, and I'm not about to bother checking. At
any rate they control access to segment tables, that have such
things as segment limits and access allowances recorded. So every
'386 up compiler already uses a minimum of 48 bits for a pointer,
it just uses a common value for the part past the first 32 bits.

No, it is using a 32 bit pointer with 'magic'. Do sizeof(char*) and it
will be 4, not 6 (with CHAR_BIT == 8).

It is theoretically possible to have an x86 compiler which used segment
+ a 32 bit offset, and therefore 48 (or more) pointers, but I've never
heard of one actually doing it. It could be very useful (for instance
to force every object into its own segment for memory protection).

Chris C

 

[CBFalconer]

.... snip ...

The OP was talking about IMPLEMENTATIONS ie the real world tools
that talk t the real world hardware.

this is why newly qualified graduates are usually considered
dangerous when they enter the work place. They know the theory
but have yet to learn the harsh realities of life.

Some C compilers do have 8 bit shorts and enums.

Why in heavens name should they? They presumably have 8 bit bytes,
and can go ahead and do arithmetic and storage with those. They
have absolutely no need for an 8 bit short. Its only purpose seems
to be to make the code non-portable.

I would much rather develop and test as much as possible of my code
on a full fledged system, with such things as easy modification,
debug tracking, etc. etc. etc. I don't need such debugged modules
and functions suddenly failing because they are running on an
inferior system.