2016-01-05 2:28 GMT-08:00 Charles Forsyth <[email protected]>: > since 6c is more commonly used now, and there's more interest or need, it's > probably best just to introduce > the difference type and change the result type. it's the same thing with > usize.
i get that probably nobody cares about c standards here, but it might be useful to mention what c99 and c11 say about this issue, since the behavior is well-defined for every other c implementation (and minus having a ptrdiff_t type, there's actually nothing wrong with the current behavior). the latest particulars in c11 defining ptrdiff_t and pointer addition and subtraction are at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf page 93. ptrdiff_t was introduced in c99. the type specifies behavior of pointer subtraction where the pointers point to elements within an array object. the size of this type is implementation defined. when the pointers are not both pointer to members of the same array object (or one past it), or when the difference of the subtraction falls out of the range of the implementation's ptrdiff_t type, the behavior is undefined. i think practically, this means that the behavior is undefined if the pointers belong to two separate memory allocations since variable-length arrays are array objects *and* are dynamically allocated -- so this isn't making a strong statement that the pointers have to be inside something declared `T foo[N]`, but it is making a statement that they have to be inside or one past a contiguous memory region of the same type (and could alias). so given any of the examples in this thread, if you typedef'ed ptrdiff_t to long, then the compiler technically isn't actually doing anything wrong. whether it is doing something useful is a different question. for practical purposes, if the compiler learned about a ptrdiff_t type (or whatever you feel like calling it), and that type was 64 bits, it would be enough to represent the difference between any two physical addresses that amd64 could represent. for instance, although the range of subtraction is theoretically -2^64+1 to 2^64-1, amd64 can only address 48 bits of memory (currently) despite using 64 bits to represent addresses. as long as virtual addresses in the system aren't exabytes apart, this shouldn't result in undefined behavior in practice.
