size of pointers and architecture

Question

By conducting a basic test by running a simple C++ program on a normal desktop PC it seems plausible to suppose that sizes of pointers of any type (including pointers to fun

Answer 1

No, it is not reasonable to assume. Making this assumption can cause bugs.

The sizes of pointers (and of integer types) in C or C++ are ultimately determined by the C or C++ implementation. Normal C or C++ implementations are heavily influenced by the architectures and the operating systems they target, but they may choose the sizes of their types for reasons other than execution speed, such as goals of supporting smaller memory use, supporting code that was not written to be fully portable to any type sizes, or supporting easier use of big integers.

I have seen a compiler targeted for a 64-bit system but providing 32-bit pointers, for the purpose of building programs with smaller memory use. (It had been observed that the sizes of pointers were a considerable factor in memory consumption, due to the use of many structures with many connections and references using pointers.) Source code written with the assumption that the pointer size equalled the 64-bit register size would break.

Answer 2

For correctness, you cannot assume anything. You have to check and be prepared to deal with weird situations.

As a general rule of thumb, it is a reasonable default assumption.

It's not universally true though. See the X32 ABI, for example, which uses 32bit pointers on 64bit architectures to save a bit of memory and cache footprint. Same for the ILP32 ABI on AArch64.

So, for guesstimating memory use, you can use your assumption and it will often be right.

Answer 3

It is reasonable to assume that in general sizes of pointers of any type (including pointers to functions) are equal to the target architecture bits

Depends. If you're aiming for a quick estimate of memory consumption it can be good enough.

(including pointers to functions)

But here is one important remark. Although most pointers will have the same size, function pointers may differ. It is not guaranteed that a void* will be able to hold a function pointer. At least, this is true for C. I don't know about C++.

So I was wondering what would be such circumstances if any?

It can be tons of reasons why it differs. If your programs correctness depends on this size it is NEVER ok to do such an assumption. Check it up instead. It shouldn't be hard at all.

You can use this macro to check such things at compile time in C:

#include <assert.h>
static_assert(sizeof(void*) == 4, "Pointers are assumed to be exactly 4 bytes");

When compiling, this gives an error message:

$ gcc main.c 
In file included from main.c:1:
main.c:2:1: error: static assertion failed: "Pointers are assumed to be exactly 4 bytes"
 static_assert(sizeof(void*) == 4, "Pointers are assumed to be exactly 4 bytes");
 ^~~~~~~~~~~~~

If you're using C++, you can skip #include <assert.h> because static_assert is a keyword in C++. (And you can use the keyword _Static_assert in C, but it looks ugly, so use the include and the macro instead.)

Since these two lines are so extremely easy to include in your code, there's NO excuse not to do so if your program would not work correctly with the wrong pointer size.

Answer 4

Historically, on microcomputers and microcontrollers, pointers were often wider than general-purpose registers so that the CPU could address enough memory and still fit within the transistor budget. Most 8-bit CPUs (such as the 8080, Z80 or 6502) had 16-bit addresses.

Today, a mismatch is more likely to be because an app doesn’t need multiple gigabytes of data, so saving four bytes of memory on every pointer is a win.

Both C and C++ provide separate size_t, uintptr_t and off_t types, representing the largest possible object size (which might be smaller than the size of a pointer if the memory model is not flat), an integral type wide enough to hold a pointer, and a file offset (often wider than the largest object allowed in memory), respectively. A size_t (unsigned) or ptrdiff_t (signed) is the most portable way to get the native word size. Additionally, POSIX guarantees that the system compiler has some flag that means a long can hold any of these, but you cannot always assume so.

Answer 5

It is reasonable to assume that in general sizes of pointers of any type (including pointers to functions) are equal to the target architecture bits?

If you look at all types of CPUs (including microcontrollers) currently being produced, I would say no.

Extreme counterexamples would be architectures where two different pointer sizes are used in the same program:

x86, 16-bit

In MS-DOS and 16-bit Windows, a "normal" program used both 16- and 32-bit pointers.

x86, 32-bit segmented

There were only a few, less known operating systems using this memory model.

Programs typically used both 32- and 48-bit pointers.

STM8A

This modern automotive 8-bit CPU uses 16- and 24-bit pointers. Both in the same program, of course.

AVR tiny series

RAM is addressed using 8-bit pointers, Flash is addressed using 16-bit pointers.

(However, AVR tiny cannot be programmed with C++, as far as I know.)

Answer 6

It is reasonable to assume that in general sizes of pointers of any type (including pointers to functions) are equal to the target architecture bits?

It might be reasonable, but it isn't reliably correct. So I guess the answer is "no, except when you already know the answer is yes (and aren't worried about portability)".

Potentially:

• systems can have different register sizes, and use different underlying widths for data and addressing: it's not apparent what "target architecture bits" even means for such a system, so you have to choose a specific ABI (and once you've done that you know the answer, for that ABI).

• systems may support different pointer models, such as the old near, far and huge pointers; in that case you need to know what mode your code is being compiled in (and then you know the answer, for that mode)

• systems may support different pointer sizes, such as the X32 ABI already mentioned, or either of the other popular 64-bit data models described here

Finally, there's no obvious benefit to this assumption, since you can just use sizeof(T) directly for whatever T you're interested in.

If you want to convert between integers and pointers, use intptr_t. If you want to store integers and pointers in the same space, just use a union.