Are all data pointers the same size in one platform for all data types? [duplicate]

Asked 6/8, 2009 at 20:26 Answered 7/8, 2009 at 3:43

Are char*, int*, long* or even long long* of same size (on a given platform)?

Hobbism answered 6/8, 2009 at 20:26 Comment(6)

My curiosity begs the question: Why do you care? :-) – Kragh 6/8, 2009 at 20:29

char c[100]; int *i; i = &c[0]; i = 0x5555u; question: c[0] == 0x55u? c[1] == 0x55u? – Hobbism 6/8, 2009 at 21:25

Assigning the address of a char to a pointer to int is just not a good idea.... – Badajoz 6/8, 2009 at 23:45

@c-stranger: most certainly not guaranteeed. If the machine is big-endian, then the first two bytes of c would be 0. Also, there is no guarantee that c is aligned as strictly as an int would be aligned - though it probably is. – Bloodstream 7/8, 2009 at 3:48

@Jonathan Leffler, you are incorrectly assuming int is always 4 bytes as well. – Badajoz 7/8, 2009 at 8:29

This is important question if you are writing portable c, have a struct with pointers, and you want the memory to be aligned. brewx.qualcomm.com/bws/content/gi/common/appseng/en/… – Loux 5/10, 2012 at 21:48

They're not guaranteed to be the same size, although on the platforms I have experience with they usually are.

C 2011 online draft:

6.2.5 Types
...
28 A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.⁴⁸⁾ Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements. All pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types need not have the same representation or alignment requirements.
^{48) The same representation and alignment requirements are meant to imply interchangeability as
arguments to functions, return values from functions, and members of unions.}

Cholesterol answered 6/8, 2009 at 20:40 Comment(1)

+1 for a reference to the Standard that really nails it down and covers all edge cases. – Confucianism 6/8, 2009 at 20:46

Not necessarily. The standard does not guarantee sizeof(double*) == sizeof(int*). For instance, assume a processor with two address buses with different widths (like on some Harvard architecture processors) it could have pointers with different sizes.

Therese answered 6/8, 2009 at 20:28 Comment(14)

However, note that a void * has to be able to hold any data pointer. – Dissuade 6/8, 2009 at 20:31

Hmmm. Then why can a void* point to anything, and be properly dereferenced? After all, no information is carried along with a pointer. – Theomania 6/8, 2009 at 20:33

void* cannot be dereferenced directly - you have to cast it back to the original type. Presumably, even if representation of pointers actually differs between types, the original representation will be restored when you cast back. – Confucianism 6/8, 2009 at 20:34

WRONG. The size of the pointer is not the same thing as the size of the block of memory the pointer "points" to... – Tempi 6/8, 2009 at 20:36

Charles, you misunderstand what is talked about. It has nothing to do with size of int and double (it could be any other two types). The point is that sizes of pointers themselves can differ. – Confucianism 6/8, 2009 at 20:37

@Pavel Minaev... obviously. "Properly dereferenced" means just what it says. – Theomania 6/8, 2009 at 20:39

@Pavel, sorry, you are obviously correct, I read sizeof() and assumed you were measuring the size of the object the pointer is pointing to.... As I have never seen an use of the sizeof operator on a pointer, it would seem to make no sense to me to do that...) – Tempi 6/8, 2009 at 20:44

@CharlesBretana using sizeof on a pointer is common when invoking malloc ! – Jeffersonjeffery 16/10, 2014 at 22:20

@Matt McNabb, I guess if it's possible for pointers to come in different sizes on the same machine, (which I was unaware of), then it would make sense to use sizeof() on a pointer. Absent that scenario, it makes no sense at all - they would always be the same size... – Tempi 17/10, 2014 at 13:50

@CharlesBretana you still have to do sizeof on one of them in order to figure out how many bytes to allocate when allocating an array of pointers, since malloc expects a number of bytes. – Jeffersonjeffery 18/10, 2014 at 1:17

@Matt, but isn't the sizeof() used for malloc() the size of the object the pointer points to, not the size of the pointer? the number of bytes passed to malloc is the number of bytes of memory to be allocated, which is the number of bytes per object, times how many objects.... not the number of bytes in pointers to those objects... – Tempi 20/10, 2014 at 14:4

@CharlesBretana I'm talking about when you are allocating space to store pointers – Jeffersonjeffery 20/10, 2014 at 18:54

ahhhh, but I was not... I was talking about why you would need sizeof(somePointer) for a malloc on a machine where pointers are all always the same size... Clearly, if they're always 8 bytes, it is silly to run sizeof(). – Tempi 20/10, 2014 at 21:1

@CharlesBretana: It's not silly at all. sizeof (except perhaps when applied to a variable-length array type) has exactly zero overhead; it resolves to a constant. sizeof (some_type*) is better than 8 simply because it's more explicit -- and it means the code might be portable to other systems. – Uro 26/6, 2015 at 20:48

On 16-bit embedded processors which have banked (paged) RAM and/or flash, the use of pages may lead to pointers being different sizes - though this is independent of the size of the data they point to.

For example, on Freescale's HCS12 processor which has banked flash, data pointers are all 16 bits.

However, function pointers are 16 bits for near pointers (for code in the same page as the calling function, or in unbanked flash), or 24 bits for far pointers (for code in a different page), incorporating the page number in the address.

Things are complicated if you want to store constant data in paged flash, as due to the limitation on data pointer size, the function using the data has to be in the same page as the data being accessed.

It is conceivable that a 16-bit processor with banked RAM would likewise have different sizes for near and far data pointers.

Sculpturesque answered 6/8, 2009 at 22:54 Comment(1)

The object pointer part isn't true since HCS12 is Von Neumann and you can store objects as well as functions anywhere in flash memory just fine, optionally using banked flash. Data pointers are then either 16 or 24 bit, depending on if declared with far or not. Function pointers is a bit more advanced since not only the size of the pointer differs from 16 and 24, but you must also use the correct instructions on the assembler level: JSR versus CALL and RTS versus RTC. – Caulfield 6/10, 2021 at 13:22

Note what the C standard says - as quoted by John Bode. Note, too, that the C standard says nothing about the sizes of pointers to functions at all.

The POSIX standard lays down some extra requirements:

2.12.3 Pointer Types

All function pointer types shall have the same representation as the type pointer to void. Conversion of a function pointer to void * shall not alter the representation. A void * value resulting from such a conversion can be converted back to the original function pointer type, using an explicit cast, without loss of information.

Note: The ISO C standard does not require this, but it is required for POSIX conformance.

Bloodstream answered 7/8, 2009 at 3:43 Comment(1)

Note that this section has been removed from the POSIX 2013 revision of POSIX 2008. For most practical purposes, it still exists, but it is now a consequence of the behaviour of dlsym() rather than a more general statement. Sometime (maybe this decade), I need to write up the change. – Bloodstream 1/10, 2015 at 16:48

There is no such guarantee in either C or C++ ISO standards, but in practice, I've yet to see a platform where this doesn't hold.

Note that regardless of this, reinterpret_cast'ing one pointer to another will more often than not lead to U.B., with a few exceptions (void*, and unsigned char* for PODs). So would any union tricks. So the obvious question is: why would you care?

Confucianism answered 6/8, 2009 at 20:29 Comment(0)

When programming x86 real mode with Watcom C you could have a mixed memory model using 16-bit near pointers and 32 bit far pointers.

Tempura answered 6/8, 2009 at 20:38 Comment(0)

In the protected mode DOS days, a function pointer and a data pointer could have different lengths because data could be in a different section.

Opponent answered 6/8, 2009 at 20:30 Comment(0)

Generally yes, All pointers to anything, whether they point to a int or a long or a string or an array of strings or a function, point to a single memory address, which is the same size on a machine. That is because the Processer on a machine has a an address register that these pointers are loaded into, and the size of that address register controls the size of the pointers.

The only exception might be in cases like old Intel 8088 16-bit machines where there was a two step process to determine the memory address, involving a 16 bit segment pointer, (which identified a 64K block of memory within the 1MByte address space), and then a second 16 bit memory address to identify the specific memory address within that segment. These two 16 bit addresses were then combined to get the complete 20 bit memory address. In that scenario, then, I imagine it might be possible to distinquiah between the individual 16 bit addresses, and the combined 20-bit address.

Tempi answered 6/8, 2009 at 20:29 Comment(5)

There's no requirement for a C/C++ implementation to actually store a raw memory address in the storage location of the pointer. It can be a handle, for example (e.g. to implement pointer bounds checking). – Confucianism 6/8, 2009 at 20:33

@Pavel, I confess that I'm not a C++ person, and I only know about Handles periphally, but as a Handle is a type of pointer, than I would venture that it has to be the same size as all other pointers on the machine. – Tempi 6/8, 2009 at 20:40

A handle is not a type of pointer. A handle is an opaque identifier. It can be absolutely anything - for example, an index into some array elsewhere. – Confucianism 6/8, 2009 at 20:43

Especially true of member function pointers. I got schooled on this topic recently: there is no guarantee a pointer is actually an address. It's just the best representation on most systems we use. – Gilletta 6/8, 2009 at 21:35

Consider a word-addressed CPU, where a machine address specifies the address of, say, a 32-bit word. A pointer to a smaller type, such a char* (let's assume CHAR_BIT == 8) might need to hold both a word pointer and a byte offset within the word. I've worked on Cray vector systems that did something similar, except that the byte offset was stored in the otherwise unused high-order 3 bits of the 64-bit word. – Uro 26/6, 2015 at 20:51

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags