Editing Pointer (computer programming) (section)

==Typed pointers and casting==
In many languages, pointers have the additional restriction that the object they point to has a specific [[datatype|type]]. For example, a pointer may be declared to point to an [[integer]]; the language will then attempt to prevent the programmer from pointing it to objects which are not integers, such as [[floating-point number]]s, eliminating some errors.

For example, in C

<syntaxhighlight lang="C">
int *money;
char *bags;
</syntaxhighlight>

<code>money</code> would be an integer pointer and <code>bags</code> would be a char pointer.
The following would yield a compiler warning of "assignment from incompatible pointer type" under [[GNU Compiler Collection|GCC]]

<syntaxhighlight lang="C">
bags = money;
</syntaxhighlight>

because <code>money</code> and <code>bags</code> were declared with different types.
To suppress the compiler warning, it must be made explicit that you do indeed wish to make the assignment by [[Type conversion|typecasting]] it

<syntaxhighlight lang="C">
bags = (char *)money;
</syntaxhighlight>

which says to cast the integer pointer of <code>money</code> to a char pointer and assign to <code>bags</code>.

A 2005 draft of the C standard requires that casting a pointer derived from one type to one of another type should maintain the alignment correctness for both types (6.3.2.3 Pointers, par. 7):<ref>[http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf WG14 N1124], [http://www.open-std.org/jtc1/sc22/wg14/www/standards.html C – Approved standards: ISO/IEC 9899 – Programming languages – C], 2005-05-06.</ref>
<syntaxhighlight lang="C">
char *external_buffer = "abcdef";
int *internal_data;

internal_data = (int *)external_buffer;  // UNDEFINED BEHAVIOUR if "the resulting pointer
                                         // is not correctly aligned"
</syntaxhighlight>

In languages that allow pointer arithmetic, arithmetic on pointers takes into account the size of the type. For example, adding an integer number to a pointer produces another pointer that points to an address that is higher by that number times the size of the type. This allows us to easily compute the address of elements of an array of a given type, as was shown in the C arrays example above. When a pointer of one type is cast to another type of a different size, the programmer should expect that pointer arithmetic will be calculated differently. In C, for example, if the <code>money</code> array starts at 0x2000 and <code>sizeof(int)</code> is 4 bytes whereas <code>sizeof(char)</code> is 1 byte, then <code>money + 1</code> will point to 0x2004, but <code>bags + 1</code> would point to 0x2001. Other risks of casting include loss of data when "wide" data is written to "narrow" locations (e.g. <code>bags[0] = 65537;</code>), unexpected results when [[Bit shift|bit-shifting]] values, and comparison problems, especially with signed vs unsigned values.

Although it is impossible in general to determine at compile-time which casts are safe, some languages store [[run-time type information]] which can be used to confirm that these dangerous casts are valid at runtime. Other languages merely accept a conservative approximation of safe casts, or none at all.

=== Value of pointers ===
In C and C++, even if two pointers compare as equal that doesn't mean they are equivalent. In these languages ''and'' [[LLVM]], the rule is interpreted to mean that "just because two pointers point to the same address, does not mean they are equal in the sense that they can be used interchangeably", the difference between the pointers referred to as their ''provenance''.<ref>{{cite web |last1=Jung |first1=Ralf |title=Pointers Are Complicated II, or: We need better language specs |url=https://www.ralfj.de/blog/2020/12/14/provenance.html}}</ref> Casting to an integer type such as <code>uintptr_t</code> is implementation-defined and the comparison it provides does not provide any more insight as to whether the two pointers are interchangeable. In addition, further conversion to bytes and arithmetic will throw off optimizers trying to keep track the use of pointers, a problem still being elucidated in academic research.<ref>{{cite web |title=Pointers Are Complicated, or: What's in a Byte? |url=https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html |last1=Jung|first1=Ralf}}</ref>