What is the size of a pointer? What exactly does it depend on?

Question

I searched online and while I could find a few discussions, I did not find a comprehensive description. So if anyone could form an answer which covers everything about size of a pointer, it would be of great help. The answer should at least cover following topics

1. What does the size of a pointer depend on?
2. What feature of architecture affects the size of a pointer? (In detail)
3. How does the compiler affect the size of a pointer?

Solution 1

A pointer is an abstraction provided by a high-level language; in theory it could be any width at all. It's totally at the whim of the compiler.

In practice, it's typically related to the width of the memory addresses of the underlying hardware, as that's usually the most efficient thing for the compiler to implement. There are exceptions though; for example, C++'s pointer-to-member-function does not have a direct mapping to hardware addresses, as it needs to represent two entities (the function and some notion of the type).

However, even leaving that aside, there are still complexities. For example:

• On most modern hardware, your program will work with virtual memory addresses, rather than physical addresses (which may not be the same width). Unless you're writing kernel-space code.
• On some architectures (e.g. x86), the underlying hardware exhibits a segmented address space. This is really complicated, but is mostly abstracted away by the OS and the virtual-memory system. If you're writing kernel-space code or code for really old x86s, you'll have to deal with it, though.
• On current x86-64, (virtual) memory addresses are actually only 48-bits wide.
• x86-64 supports both 32-bit and 64-bit executables.
• You may be running inside a virtual machine, which again can do whatever if it wants (relative to the underlying physical machine).

Solution 2

^{This question was originally tagged C and C++, not “language agnostic”. As a language-agnostic question it should be closed as being too broad, but I’m hoping that the OP will revert it to the original versionl, and so I'm not voting to close. As a C/C++ question, while eminently answerable it was closed as being too broad, and then when the scope was enormously broadened to unanswerable, by changing that tagging to language-agnostic, it was reopened as being now answerable.}

^{I’m answering the original question for C++, with a few bits of C knowledge sprinkled here and there.}

^{I think the current “language-agnostic” question is unanswerable in spite of one attempted language-agnostic answer.}

1. What does the size of a pointer depend on?

The minimum required size of an ordinary data pointer depends on the maximum number of possible memory locations of objects of the pointed-to type, or of different functions; to differentiate n possible locations ceil(lg2(n)) bits are needed.

Hence the minimum pointer size depends on maximum possible memory size.

And hence the minimum pointer size also depends on the alignment of the pointed-to type. On some now archaic machines, and possibly even on some extant machines (mainframe?), the hardware level addressable unit of memory was a word of e.g. 2 or 4 bytes. Word aligned data could then be addressed with small pointers, while char* and hence also void* needed to be larger.

Consequently, the C++11 standard in §3.9.2/4 requires that “An object of type cv void* shall have the same representation and alignment requirements as cv char*.”

Member function pointers in C++ are more akin to offsets than pointers, and are often larger than proper pointers.

---

2. What feature of architecture affects the size of a pointer? (In detail)

Mainly the adressable range of memory as seen from C++.

But also it's worth recalling that in MS-DOS programming one differentiated between near and far pointers. A near pointer was an offset into an implied 64K segment of memory, while a far pointer, twice the size, combined a segment selector and offset.

In (still) modern 32-bit PC programming C and C++ pointers are as a rule akin to near pointers, with no support for far pointers, which would be 6 bytes. To use such pointers it's necessary to use other languages such as assembly language.

---

3. Does the compiler affect the size of a pointer? How?

The compiler and compilation options used can in principle affect the pointer size, because the size is not prescribed by the standard. E.g. it can in principle add information to aid with debugging. Or as mentioned, with language extensions there can be near and far pointers.

Since member pointers are not directly addresses (under the hood), it's very much up to the compiler how to represent them, and how large they are.

This can also depend on the options used.

---

4. What are the different types of pointers and how are they different from each other? (Eg: Is there a difference between function pointers and a pointer pointing to a basic data type?, near pointer vs far pointer etc)

In C++03 a function pointer could not be converted to a data pointer or vice versa. This restriction supported machines with Harvard architecture, and it supported possible different sizes of function pointers and data pointers (e.g. with the former as far and the latter as near). In C++11 such conversion is conditionally supported, in §5.2.10/8, resulting from Defect Report 195.

It's worth noting that the Posix standard requires support for conversion (function pointer) → (void*) and back, e.g. for the dlsym function.

The above effectively means that object pointers and functions pointers are different. E.g. the latter don't support address arithmetic. Also, member pointers are different from proper pointers, and are more akin to offsets.

Modern C++ does not support near versus far pointers.

---

5. Does the language have any effect on pointer. C vs C++

C doesn't support member pointers, to the degree that they are considered pointers in this question.

Other than that, a main goal of C++ is to be able to use C libraries directly, and the C standard is “incorporated” (C++11 §17.5.1.5/1) into the C++ standard, which requires compatible pointer representations.

C supports restricted pointers, the qualifier restrict, which C++ doesn't support. However, this only affects the knowledge that the compiler has about the possible values of a pointer. Which means that a C compiler might be able to emit better optimized code.

Comments

[Oliver Charlesworth]

A pointer is a high-level language construct; in theory it could be any width at all. A memory address, on the other hand, is a physical construct.

[Some programmer dude]

On a modern PC the size of a pointer depends on the size of the native word length (32 or 64 bits). But there's nothing to say that a pointer have to be a specific length or size, or even that the size of pointers have to be uniform on a single platform using a single compiler. For example, pointers to integers could be one size but pointers to functions could be another.

[Cheers and hth. - Alf]

I fail to see how this question can be too broad. It has 5 simple sub-questions. All are easy to answer, and do have specific answers. Please do not vote to close just because you're unable to answer the question. Let others have a chance both to contribute and to learn, not to mention to google this up in the future.

[Oliver Charlesworth]

@Cheersandhth.-Alf: IMHO, answering everything the OP is asking will take pages; some of the sub-questions are themselves pretty broad (e.g. "What are the different types of pointer"). That said, if you have an answer ready to go, let me know and I'll provide the remaining re-open vote ;)

[mrbubz]

Removal of C/C++ and adding language-agnostic tags was done by one of the moderators. I don't know if I should rollback. Then the question will be threatened to be closed down because someone pointed out it has nothing to do with C/C++ earlier.

[Cheers and hth. - Alf]

@sudhirvyasaraja: if someone alleged that it has nothing to do with C/C++, then that someone was simply wrong. for example, this answer cites a number of paragraphs from the current C++ standard, as well as a C++ defect report. it's not unusual on SO that people make various unfounded claims to support their stance (the lack of discussion support means that it's impractical and not very convincing to try to deal with an avalanche of plausible-sounding claims).

[Ben Voigt]

This is very Intel-centric. C++ has no concept of segments and offsets or far addresses. But that does show that pointer size is determined by address space, not memory size. (Intel centrism is especially ironic when you trashed Oli's answer for making much broader architectural assumptions)

[Ben Voigt]

@sudhirvyasaraja: Well, you should make your question relevant to C and C++. For example, say "size of a pointer in C++"

[Ben Voigt]

@Alf: I guess you've never worked on an architecture where there exists more than one address for the same memory location, with different read/write access, different caching characteristics, etc? But wait, there's one right there in your answer -- the segmented address model of DOS. Note that I didn't say that your answer was wrong, I'm just asking you to show some consistency and identify when you're talking about a specific architecture and not 100% portable C++, since you demand that others do that.

[Cheers and hth. - Alf]

Ben Voigt's This is very Intel-centric, his first sentence, has no connection to anything in the answer, even though it appears as a comment on the answer. It doesn't have a connection to anything else that I know of, either. And so it goes for his second sentence, his third sentence, and so on: nothing he writes above is correct or truthful. I find it hard to imagine why he does this.

[Lightness Races in Orbit]

@sudhir: No moderator touched the tags on this question.