Sizeof for pointers

[Avinash]

Hi,

I just wanted to confirm that sizeof for a pointer always returns the
same value on a machine.
I would appreciate if somebody would respond to this.

Thanks.

[Richard Heathfield]

Avinash said:

Hi,

I just wanted to confirm that sizeof for a pointer always returns the
same value on a machine.

It doesn't. I have a machine right here with different compilers on it,
which use different sizes for the same kind of pointer.

But on a given machine, using a given version of a given compiler with given
options, I think it's probably safe to say that the size of a pointer won't
change. What is certainly safe to say is that, within a program run,
pointer size is fixed.

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

[sjdevnull]

Richard Heathfield wrote:

It doesn't. I have a machine right here with different compilers on it,
which use different sizes for the same kind of pointer.

But on a given machine, using a given version of a given compiler with given
options, I think it's probably safe to say that the size of a pointer won't
change. What is certainly safe to say is that, within a program run,
pointer size is fixed.

Just to emphasize a point Richard makes here, the size of a particular
type of pointer won't change under those conditions; it's possible
that, say, a void pointer and a function pointer can have different
sizes.

[Keith Thompson]

"Avinash" <av******@gmail.comwrites:

I just wanted to confirm that sizeof for a pointer always returns the
same value on a machine.
I would appreciate if somebody would respond to this.

The same value as what?

On many implementations, all pointers are the same size, but it's not
guaranteed by the language. You can probably assume that sizeof will
yield the same value for the same type in the same implementation
(some compiler options may in effect cause it to be a different
implementation). Beyond that, there's seldom a reason to write code
that assumes that all pointers have the same size.

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

[christian.bau]

Avinash wrote:

Hi,

I just wanted to confirm that sizeof for a pointer always returns the
same value on a machine.
I would appreciate if somebody would respond to this.

Thanks.

"On one machine" is very unclear. Many people can for example run 32
bit PowerPC, 32 bit x86 and 64 bit x86 code on the same machine, and I
surely expect them to have different pointer sizes on the same machine.
You probably mean "on one implementation".

On one implementation, it wouldn't be at all surprising if function
pointers and data pointers have different sizes. All pointers to struct
must have the same size; all pointers to unions must have the same
size, things like int*, const int*, volatile int* must have the same
size. char* and void* must have the same size. Pointers to structs and
for example pointers to chars can have different sizes, and there are
implementations where the sizes are actually different.

[Avinash]

Yes, I meant "on one implementation" and the same compiler.
Why do we have different pointer sizes for struct and data pointers?
I mean for eg on a 32-bit machine, can't a struct and some data (char,
int etc) be accessed using a 32-bit address. So is'nt it sufficient if
all pointers have the ability to hold 32-bit information and thus
ensure uniformity in pointer size, or am I missing some special case.
Also, by data pointers I guess you also include float *, double * and
other access specifiers (volatile float *, const float *, const double
*, volatile double* etc).
christian.bau wrote:

Avinash wrote:

Hi,

I just wanted to confirm that sizeof for a pointer always returns the
same value on a machine.
I would appreciate if somebody would respond to this.

Thanks.

"On one machine" is very unclear. Many people can for example run 32
bit PowerPC, 32 bit x86 and 64 bit x86 code on the same machine, and I
surely expect them to have different pointer sizes on the same machine.
You probably mean "on one implementation".

On one implementation, it wouldn't be at all surprising if function
pointers and data pointers have different sizes. All pointers to struct
must have the same size; all pointers to unions must have the same
size, things like int*, const int*, volatile int* must have the same
size. char* and void* must have the same size. Pointers to structs and
for example pointers to chars can have different sizes, and there are
implementations where the sizes are actually different.

[Michal Nazarewicz]

"Avinash" <av******@gmail.comwrites:

Why do we have different pointer sizes for struct and data pointers?

From http://www.parashift.com/c++-faq-lit....html#faq-26.6

The PDP-10 has 36-bit words with no hardware facility to address
anything within one of those words. That means a pointer can point
only at things on a 36-bit boundary: it is not possible for a
pointer to point 8 bits to the right of where some other pointer
points.

[...] Another valid approach would be to define a "byte" as 9
bits, and simulate a char* by two words of memory: the first could
point to the 36-bit word, the second could be a bit-offset within
that word. In that case, the C++ compiler would need to add extra
instructions when compiling code using char* pointers. For
example, the code generated for *p = 'x' might read the word into
a register, then use bit-masks and bit-shifts to change the
appropriate 9-bit byte within that word. An int* could still be
implemented as a single hardware pointer, since C++ allows
sizeof(char*) != sizeof(int*).

It's C++ FAQ but same applies to C.

I mean for eg on a 32-bit machine, can't a struct and some data (char,
int etc) be accessed using a 32-bit address.

It probably can but standard does not guarantee that your program will
run on 32-bit machine.

So is'nt it sufficient if all pointers have the ability to hold
32-bit information and thus ensure uniformity in pointer size, or am
I missing some special case.

You do - a case where your program is running on some "strange"
architecture. ;)

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--

[Richard Heathfield]

sj*******@yahoo.com said:

Richard Heathfield wrote:

>It doesn't. I have a machine right here with different compilers on it,
which use different sizes for the same kind of pointer.

But on a given machine, using a given version of a given compiler with
given options, I think it's probably safe to say that the size of a
pointer won't change. What is certainly safe to say is that, within a
program run, pointer size is fixed.

Just to emphasize a point Richard makes here, the size of a particular
type of pointer won't change under those conditions; it's possible
that, say, a void pointer and a function pointer can have different
sizes.

Oops, yes, I should have said that, within a program run, the size of
pointers of a particular *type* is fixed. Thanks for clarifying.

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

[CBFalconer]

"sj*******@yahoo.com" wrote:

Richard Heathfield wrote:

>It doesn't. I have a machine right here with different compilers
on it, which use different sizes for the same kind of pointer.

But on a given machine, using a given version of a given compiler
with given options, I think it's probably safe to say that the size
of a pointer won't change. What is certainly safe to say is that,
within a program run, pointer size is fixed.

Just to emphasize a point Richard makes here, the size of a particular
type of pointer won't change under those conditions; it's possible
that, say, a void pointer and a function pointer can have different
sizes.

Also that a void* and a double* have different sizes. The only
requirement is that an arbitrary pointer can be converted to a
void* and back again (to the same type) without losing any
information.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[CBFalconer]

Avinash wrote:

>
Yes, I meant "on one implementation" and the same compiler.
Why do we have different pointer sizes for struct and data pointers?
I mean for eg on a 32-bit machine, can't a struct and some data (char,
int etc) be accessed using a 32-bit address. So is'nt it sufficient if
all pointers have the ability to hold 32-bit information and thus
ensure uniformity in pointer size, or am I missing some special case.
Also, by data pointers I guess you also include float *, double * and
other access specifiers (volatile float *, const float *, const double
*, volatile double* etc).

Don't top-post. See the following links.

--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

[Martin Ambuhl]

Michal Nazarewicz wrote:

"Avinash" <av******@gmail.comwrites:

>Why do we have different pointer sizes for struct and data pointers?

From http://www.parashift.com/c++-faq-lit....html#faq-26.6

The PDP-10 has 36-bit words with no hardware facility to address
anything within one of those words. That means a pointer can point
only at things on a 36-bit boundary: it is not possible for a
pointer to point 8 bits to the right of where some other pointer
points.

This is very misleading. The PDP-10 had machine-level byte pointers
which specified a 36-bit word boundary and an offset. One could load or
store bytes, with or without increment or decrement of the byte pointer,
at the assembly level. Pointers *do* point other that at 36-bit
boundaries. Further, there is a complete set of half-word (left and
right 18-bit) instructions. The PDP-10 had one of the richest
addressing schemes available. Whoever wrote that FAQ chose his example
poorly. Maybe C++ people need several layers of obfuscation above the
machine level.

[Barry Schwarz]

On 3 Dec 2006 02:49:43 -0800, "Avinash" <av******@gmail.comwrote:

>Yes, I meant "on one implementation" and the same compiler.
Why do we have different pointer sizes for struct and data pointers?

Whether the sizes are different or not is a design decision made by
the compiler writer, probably based on factors such as:
what does the hardware require
what does the operating system require
what simplifies the code generating portion of the compiler
what are the conventions used by non-C runtime libraries popular
on this system
what are my personal preferences
etc

The real question is "Why do you care?" Is there part of your code
that needs to know? If so, please describe it. Someone may be able
to offer an alternative that is not dependent on the information and
thereby make your code that much more portable.
Remove del for email

[sjdevnull]

CBFalconer wrote:

"sj*******@yahoo.com" wrote:

Just to emphasize a point Richard makes here, the size of a particular
type of pointer won't change under those conditions; it's possible
that, say, a void pointer and a function pointer can have different
sizes.

Also that a void* and a double* have different sizes.

Yes.

The only
requirement is that an arbitrary pointer can be converted to a
void* and back again (to the same type) without losing any
information.

I thought that function pointers in particular could not be portably
converted to void pointers (and FAQ 4.13 seems to agree).

[Kenny McCormack]

In article <45***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>Avinash wrote:

>>
Yes, I meant "on one implementation" and the same compiler.
Why do we have different pointer sizes for struct and data pointers?
I mean for eg on a 32-bit machine, can't a struct and some data (char,
int etc) be accessed using a 32-bit address. So is'nt it sufficient if
all pointers have the ability to hold 32-bit information and thus
ensure uniformity in pointer size, or am I missing some special case.
Also, by data pointers I guess you also include float *, double * and
other access specifiers (volatile float *, const float *, const double
*, volatile double* etc).

Don't top-post. See the following links.

--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

Yes, and don't forget these, far more helpful, informative, and topical links:

http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/C_programming_language

[Keith Thompson]

"sj*******@yahoo.com" <sj*******@yahoo.comwrites:
[...]

I thought that function pointers in particular could not be portably
converted to void pointers (and FAQ 4.13 seems to agree).

That's correct. This leads to the periodic discussion of how you can
portably print the value of a function pointer. (You can't, but you
can print its representation by treating the pointer as an array of
unsigned char.)

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

[Dave Thompson]

<OT>
On Sun, 03 Dec 2006 13:36:30 -0500, Martin Ambuhl
<ma*****@earthlink.netwrote:

Michal Nazarewicz wrote:

"Avinash" <av******@gmail.comwrites:

Why do we have different pointer sizes for struct and data pointers?

From http://www.parashift.com/c++-faq-lit....html#faq-26.6

The PDP-10 has 36-bit words with no hardware facility to address
anything within one of those words. That means a pointer can point
only at things on a 36-bit boundary: it is not possible for a
pointer to point 8 bits to the right of where some other pointer
points.

This is very misleading. The PDP-10 had machine-level byte pointers
which specified a 36-bit word boundary and an offset. One could load or

and length (width).

store bytes, with or without increment or decrement of the byte pointer,
at the assembly level. Pointers *do* point other that at 36-bit

or increment alone, or (as of KL10 IIRC) increment N times;

and the mnemonics LDB (load byte, "lud-bee") and DPB (store byte,
"dip-bee"), and less often the increment forms were for a long time
accepted if somewhat silly hackish for "get something from / put
something to the middle of something else".

boundaries. Further, there is a complete set of half-word (left and
right 18-bit) instructions. The PDP-10 had one of the richest
addressing schemes available. Whoever wrote that FAQ chose his example

One of the richer instruction (operation) sets of its time, including
all 2^4 two-operand bitwise operations, and multiple indirection which
had some interesting <Guses, but not otherwise very rich addressing.
Compare to -11 (register & indirect, autoinc & autodec ditto, constant
& absolute, offset & indirect, relative & indirect) (and soon after
VAX with even more, and 68k), and even S/360 (offset + base + index).

poorly. Maybe C++ people need several layers of obfuscation above the
machine level.

I believe some of the _other_ 36-bit or wider machines did have
difficulty with variable subword addressing -- GE/HIS? Cyber?

- David.Thompson1 at worldnet.att.net