size of pointer in C?

[Alexei A. Frounze]

....

The quickest way to find out what pointer sizes are on your particular
implementation:

printf("sizeof(char*): %lu\n", (unsigned long) sizeof(char*));
printf("sizeof(int*): %lu\n", (unsigned long) sizeof(int*));
printf("sizeof(short*): %lu\n", (unsigned long) sizeof(short*));

And chances are that the tree will print the same number. And that's
practically on every system, if not on all.
However, sizeof(void*) and sizeof(void(*)()) are very often different,
consider the Harvard architecure (if you've always programmed in msvc++ on
x86 PC , where program and data memories aren't necessarily the same thing
and may have different width of either the address bus or data bus or both,
alsmo meaning that a byte in one space isn't necessarily equal to a byte in
the other (in bits).

Alex

 

[Keith Thompson]

...

And chances are that the tree will print the same number. And that's
practically on every system, if not on all.

Probably, but there are valid reasons why char* and void* might be
bigger, or at least have a different representation, than int*.

However, sizeof(void*) and sizeof(void(*)()) are very often different,
consider the Harvard architecure (if you've always programmed in msvc++ on
x86 PC , where program and data memories aren't necessarily the same thing
and may have different width of either the address bus or data bus or both,
alsmo meaning that a byte in one space isn't necessarily equal to a byte in
the other (in bits).

Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ. As for "byte" sizes, the C standard only uses the
term to refer to object sizes; there's no such thing as the size of a
function, in "bytes" or any other units. (A system may have such a
concept, but standard C doesn't refer to it.)

But the most important point is that, most of the time, none of this
should matter. You can write code that doesn't *care* whether
different pointer types have different sizes, and that will work
properly whether they differ or not. Just don't depend on any
assumptions that aren't guaranteed by the standard. It's often
(usually?) *easier* to write portable code than to write code that
depends on system-specific sizes.

 

[Alexei A. Frounze]

Probably, but there are valid reasons why char* and void* might be
bigger,

Bigger than what and why?

or at least have a different representation, than int*.

Like what? A few lowest signigicant bits being 0 due to alignment?

Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ. As for "byte" sizes, the C standard only uses the
term to refer to object sizes; there's no such thing as the size of a
function, in "bytes" or any other units. (A system may have such a
concept, but standard C doesn't refer to it.)
Right.

But the most important point is that, most of the time, none of this
should matter.
True.

You can write code that doesn't *care* whether
different pointer types have different sizes, and that will work
properly whether they differ or not. Just don't depend on any
assumptions that aren't guaranteed by the standard. It's often
(usually?) *easier* to write portable code than to write code that
depends on system-specific sizes.

I'm not sure of this... The practice seem to show lots of examples of the
directly opposite. Many C programmers, the beginners (including me some time
ago), do not know C and the standard well for obvious reasons -- it's new to
them and it's different from whatever they had learned or used before. If
they happen to know a bit about the CPU for which they write their C code,
they're more likely to not use sizeof for the basic types, not care about
the alignment when placing objects in memory, ignore various warnings about
prototypes, conversion/promotion, etc etc. I did it all myself. Now I don't
do it because I'm fortunate enough to have seen (correct my English here if
need be) various platforms, not just the x86. And this taught me how to do
things better. Those who are condemned to x86 and ignorance about C and its
standard, are condemned to making bad code. And it's not easier to write
portable code in that case, it's simply impossible.

Alex

 

[Keith Thompson]

Bigger than what and why?

Bigger than int* ...

... as I think I made clear in the same sentence.

The example I've brought up here several times in the past is the C
implementation on Cray vector machines. The smallest directly
addressible unit of memory is 64 bits, so the obvious value for
CHAR_BIT would be 64 -- except that the system runs a version of Unix,
and there's a need to be able to represent strings of 8-bit characters
and share information with other systems, so the implementation uses
CHAR_BIT==8. An int* (pointing to a 64-bit int) is simply a native
64-bit machine address, but a char* pointer needs to specify which
8-bit byte within the word it points to. This is done (purely in
software) by storing a 3-bit offset in the (otherwise unused)
high-order 3 bits of the pointer.

If the machine used all 64 bits of a word pointer, a byte pointer
would have to store the offset somewhere else -- i.e., it would have
to be bigger than 64 bits.

Like what? A few lowest signigicant bits being 0 due to alignment?

No, see above.

[...]

I'm not sure of this... The practice seem to show lots of examples of the
directly opposite. Many C programmers, the beginners (including me some time
ago), do not know C and the standard well for obvious reasons -- it's new to
them and it's different from whatever they had learned or used before. If
they happen to know a bit about the CPU for which they write their C code,
they're more likely to not use sizeof for the basic types, not care about
the alignment when placing objects in memory, ignore various warnings about
prototypes, conversion/promotion, etc etc. I did it all myself. Now I don't
do it because I'm fortunate enough to have seen (correct my English here if
need be) various platforms, not just the x86. And this taught me how to do
things better. Those who are condemned to x86 and ignorance about C and its
standard, are condemned to making bad code. And it's not easier to write
portable code in that case, it's simply impossible.

Perhaps the problem is in the way beginners learn C. If you learn the
language without reference to the details of the underlying machine,
you'll presumably develop the habit of writing portable code because
you don't know how not to. Learning the details of particular
implementations *later* can let you write non-portable code when
necessary, while knowing the difference. (I'm using "you" as a verbal
shorthand; I'm not referring to you personally.)

 

[Kenneth Brody]

Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ.

(Drifting slightly OT for clc, but still on-topic because it shows
that there is a "real world" platform where these things occur.)

You've never worked in the 16-bit segmented x86 architecture then,
have you? There, pointers were either 16 or 32 bits, depending on
"memory model" and whether it's a data or code pointer.

Model sizeof(void*) sizeof(void(*)())
===== ============= =================
Tiny 2 2
Small 2 2
Compact 4 2
Medium 2 4
Large 4 4
Huge 4 4

And even then, you could coerce a code/data pointer to the other
size using the (implementation-specific) "near" and "far" modifiers.

ie: sizeof(void near *)==2, sizeof(void far *)==4, regardless of
memory model.

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Keith Thompson]

Keith Thompson wrote: [...]

Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ.

(Drifting slightly OT for clc, but still on-topic because it shows
that there is a "real world" platform where these things occur.)

You've never worked in the 16-bit segmented x86 architecture then,
have you? There, pointers were either 16 or 32 bits, depending on
"memory model" and whether it's a data or code pointer.

No, I haven't.

Saying that I've never used such a system doesn't imply that they
don't exist, or even that they're particularly rare. I know my own
experience is limited in many ways. (And I know you haven't implied
otherwise; I'm just trying to be as clear as possible.)

 

[Gordon Burditt]

You've never worked in the 16-bit segmented x86 architecture then,

have you? There, pointers were either 16 or 32 bits, depending on
"memory model" and whether it's a data or code pointer.

Model sizeof(void*) sizeof(void(*)())
===== ============= =================
Tiny 2 2
Small 2 2
Compact 4 2
Medium 2 4
Large 4 4
Huge 4 4

You forgot a whole bunch of them:

32-bit tiny 4 4
32-bit small 4 4
32-bit compact 6 4
32-bit medium 4 6
32-bit large 6 6
32-bit huge 6 6 also called "intergalactic tremendously enormous"

I don't know how many compilers for 32-bit huge model actually exist,
but sooner or later Windows will need more than 4G for the boot process.

Gordon L. Burditt

 

[Alexei A. Frounze]

Bigger than int* ...


... as I think I made clear in the same sentence.

The example I've brought up here several times in the past is the C
implementation on Cray vector machines. The smallest directly
addressible unit of memory is 64 bits, so the obvious value for
CHAR_BIT would be 64 -- except that the system runs a version of Unix,
and there's a need to be able to represent strings of 8-bit characters
and share information with other systems, so the implementation uses
CHAR_BIT==8. An int* (pointing to a 64-bit int) is simply a native
64-bit machine address, but a char* pointer needs to specify which
8-bit byte within the word it points to. This is done (purely in
software) by storing a 3-bit offset in the (otherwise unused)
high-order 3 bits of the pointer.

So, let alone the representation, sizeof(char*) == sizeof(int*) anyway in
this case?

If the machine used all 64 bits of a word pointer, a byte pointer
would have to store the offset somewhere else -- i.e., it would have
to be bigger than 64 bits.

E.g. sizeof(char*) = 2*sizeof(int*) ?
What a waste

....

Perhaps the problem is in the way beginners learn C. If you learn the
language without reference to the details of the underlying machine,
you'll presumably develop the habit of writing portable code because
you don't know how not to. Learning the details of particular
implementations *later* can let you write non-portable code when
necessary, while knowing the difference. (I'm using "you" as a verbal
shorthand; I'm not referring to you personally.)

While I'd agree on the point of view, for some reason many indeed do first
learn something about the underlying hardware and then apply C to it...

Alex

 

[Kenneth Brody]

Keith Thompson wrote: [...]

Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ.

(Drifting slightly OT for clc, but still on-topic because it shows
that there is a "real world" platform where these things occur.)

You've never worked in the 16-bit segmented x86 architecture then,
have you? There, pointers were either 16 or 32 bits, depending on
"memory model" and whether it's a data or code pointer.

No, I haven't.

Not that it's necessarily a bad thing that you've never had to deal
with the segmented 16-bit real-mode of the x86 CPU...

Saying that I've never used such a system doesn't imply that they
don't exist, or even that they're particularly rare. I know my own
experience is limited in many ways. (And I know you haven't implied
otherwise; I'm just trying to be as clear as possible.)

True. But sometimes people use the argument "but _I've_ never seen
such a system" as a way of justifying the "portability" of some
piece of code.

I happen to know that the programs I work on are not 100% portable.
While many things (like screen and keyboard I/O) are modularized in
system-specific modules, other things are "portable enough" to work
on any Posix system we're likely to port to, with the occasional #if
to tweak minor sections as needed.

On the other hand, I avoid "undefined behavior" like the plague.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Kenneth Brody]

You forgot a whole bunch of them:

32-bit tiny 4 4
32-bit small 4 4
32-bit compact 6 4
32-bit medium 4 6
32-bit large 6 6
32-bit huge 6 6 also called "intergalactic tremendously enormous"

I don't know how many compilers for 32-bit huge model actually exist,
but sooner or later Windows will need more than 4G for the boot process.

Well, I did say "16-bit segmented x86 architecture".

I assume the 6-byte pointers are 16-bit selector plus 32-bit offset?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Tim Rentsch]

I don't know how many compilers for 32-bit huge model actually exist,
but sooner or later Windows will need more than 4G for the boot process.

Whew! That's a relief. I thought it did already.

 

[Kenneth Brody]

Whew! That's a relief. I thought it did already.

This is from the "setup.htm" file in the Windows Vista beta 1 install:

==========

2. When the message "Press any key to boot from CD" appears, press a
key. Windows installation begins.

* If you have an x64-based computer, you might see a blank screen
for long time. It can take 20 minutes or longer before the next
screen appears. Do not turn off your computer or restart it
during this time.

* After the blank screen, you will see a progress bar at the bottom
of the screen. This stage might also take some time to complete.

==========

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Alexei A. Frounze]

Whew! That's a relief. I thought it did already.

Maybe I missed the point or something, but Watcom C/C++ compiler has support
for far pointers being a 16-bit selector and 32-bit offset. Just if you
didn't know...

Alex

 

[Alan Balmer]

Maybe I missed the point or something, but Watcom C/C++ compiler has support
for far pointers being a 16-bit selector and 32-bit offset. Just if you
didn't know...

And it's free!