58

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

Improve this question
6
  • 2
    My curiosity begs the question: Why do you care? :-) Commented Aug 6, 2009 at 20:29
  • char c[100]; int *i; i = &c[0]; i = 0x5555u; question: c[0] == 0x55u? c[1] == 0x55u? Commented Aug 6, 2009 at 21:25
  • Assigning the address of a char to a pointer to int is just not a good idea.... Commented Aug 6, 2009 at 23:45
  • 1
    @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. Commented Aug 7, 2009 at 3:48
  • 5
    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/… Commented Oct 5, 2012 at 21:48

8 Answers 8

Reset to default
61

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.48) 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.
Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

+1 for a reference to the Standard that really nails it down and covers all edge cases.
22

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.

Improve this answer

14 Comments

However, note that a void * has to be able to hold any data pointer.
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.
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.
@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.
@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.
|
11

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.

Improve this answer

1 Comment

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

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.

Improve this answer

1 Comment

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

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?

Improve this answer

Comments

5

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.

Improve this answer

Comments

3

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.

Improve this answer

Comments

2

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.

Improve this answer

5 Comments

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.