Sizeof for pointers

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.

re: Sizeof for pointers

Avinash said:
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.

re: Sizeof for pointers

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

re: Sizeof for pointers

"Avinash" <avinashr@gmail.comwrites: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) kst-u@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.

re: Sizeof for pointers

Avinash wrote:"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.

re: Sizeof for pointers

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:

re: Sizeof for pointers

"Avinash" <avinashr@gmail.comwrites:
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.
It probably can but standard does not guarantee that your program will
run on 32-bit machine.
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--

re: Sizeof for pointers

sjdevnull@yahoo.com said:
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.

re: Sizeof for pointers

"sjdevnull@yahoo.com" wrote: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>

re: Sizeof for pointers

Avinash wrote: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/>

re: Sizeof for pointers

Michal Nazarewicz wrote: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.

re: Sizeof for pointers

On 3 Dec 2006 02:49:43 -0800, "Avinash" <avinashr@gmail.comwrote:
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

re: Sizeof for pointers

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

re: Sizeof for pointers

In article <4572E82B.77B0AA10@yahoo.com>,
CBFalconer <cbfalconer@maineline.netwrote: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

re: Sizeof for pointers

"sjdevnull@yahoo.com" <sjdevnull@yahoo.comwrites:
[...]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) kst-u@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.

re: Sizeof for pointers

<OT>
On Sun, 03 Dec 2006 13:36:30 -0500, Martin Ambuhl
<mambuhl@earthlink.netwrote:
and length (width).
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".
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).
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