4 ms·
Trouble is pointers don't have to be integers. The standard lets you address by fruit and veggies if you have such a machine.
by necheffa 6y ago
Trouble is pointers don't have to be integers. The standard lets you address by fruit and veggies if you have such a machine.
- enriquto 6y agoHowever they are implemented internally is a detail. Formally they are "affine" integers, in that you can compute the sum of an integer and a pointer to obtain another pointer, and compute the difference of two pointers to obtain an integer. I agree that "a pointer is an integer" is an over-simplification. But it is a very useful one when you are learning C. Then you will have time later to enter into the gory details, once you fully master the simple case.
- jcelerier 6y ago> and compute the difference of two pointers to obtain an integer. This is only a legal operation if those two pointers are part of the same object / allocation. It's UB (see C11 6.5.6 Additive operators ; C++ is similar) to do for instance char* ptr1 = malloc(10); char* ptr2 = malloc(10); ptr2 - ptr1; so they don't really behave like any algebraic definition of integers in that regard. Even just comparing them with (ptr1 < ptr2) is UB.
- leni536 6y agoIn C++ comparing them is unspecified, and theoretically can even change from invocation to invocation. But it's not UB. http://eel.is/c++draft/expr.rel#4.3.sentence-1 http://eel.is/c++draft/expr.rel#4.3.sentence-1 std::less is blessed by the standard to work with any two pointers, so relational containers work with pointers.
- bubblethink 6y agoThe other annoyance is the unsinged v/s signed mess in going from size_t to ptrdiff_t.
- jschwartzi 6y agoNote that in both cases your undefined behavior can be defined if the set of valid pointers is contiguous and can be represented by the integers. In that case, the return value of ptr2 - ptr1 is the difference between the two integer representations, and ptr1 < ptr2 is true when ptr1 has a smaller integer representation than ptr2, and false otherwise. So undefined behavior is not necessarily to be avoided. It needs to be evaluated on a platform-by-platform basis. It's not defined in the standard, because the standard is describing an abstract "computer" which supports the operations. However in the real world, with concrete computers such as x86 or ARM pointers have an integer representation and arithmetic and logical tests can reasonably expected to work, even if they have no standard definition in the abstract "C machine." And it's tremendously unfair and probably a bug for any "optimizing compiler" to use that undefined behavior to do anything other than subtract the two pointers and return true or false when they're logically compared.
- jcelerier 6y ago> And it's tremendously unfair and probably a bug for any "optimizing compiler" to use that undefined behavior to do anything other than subtract the two pointers and return true or false when they're logically compared. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 =)
- projektfu 6y agoIt might be true on X86 if you’re using a flat memory layout. With segmented memory or PAE, all bets are off. Thankfully PAE is usually the responsibility of the operating system which provides a flat address space to each process.
- bluetomcat 6y agoThey have to support arithmetic operations, however. Pointer offsets (p + 1) and pointer difference on the same object (p - q) should be well defined even if the pointer itself contains fruits and veggies.