Hacker News Reader

Comment by xscott | Hacker News Reader

I originally responded to your code, and you're right about it. That's not what I expected or would want to happen.

However, your code doesn't actually address my comment about conversions and arithmetic. Where does this code code fail?

    int a[2], b[2];
    uintptr_t x = (uintptr_t)a;
    uintptr_t y = (uintptr_t)b;
    uintptr_t offset = y - x;
    int* p = (int*)(x + offset);
    printf("b == p: %d\n", b==p);

I didn't try _every_ compiler on Godbolt, but I didn't see it misbehave anywhere I did try.

edit: changed to uintptr_t

View on HN

That is integer arithmetic, not pointer arithmetic. My understanding of the C memory model that is mentioned in the article (look for PNVI-ae-udi) is that what you are doing is or will be well-defined. I suspect there may still be a few implementations around where the offset you get from integer subtractions has no obvious relation to the offset you would get from pointer subtractions (for two pointers where subtraction is well-defined), but for your example that makes no difference.

> That is integer arithmetic, not pointer arithmetic.

Yeah, but I did say: "which operation could any C compiler disallow in practice: converting from pointer to integer, arithmetic on integers, or converting from integer to pointer?"

If C/C++ compilers keep breaking pointer arithmetic in the game of exploiting undefined behavior for optimizations, people are going to start doing pointer arithmetic with integers when they need it. And they do need it sometimes, for debuggers, profilers, memory checkers, JITs, garbage collectors, shared memory, and so on.

That may be good. If the pointer arithmetic with integers, or other constructs that have the effect of disabling optimisations, is kept to the code that has additional requirements beyond what the standard guarantees, that means the code out there that does not have those additional requirements, which I suspect is the majority of code, can continue to be aggressively optimised.

There's nothing in the C standard that I could find that dictates that b[] has to follow directly after a[] in memory. That it works is just happenstance (or an implementation detail). The only place were order is maintained are fields in a structure definition.

There's nothing in that example that assumes they are adjacent. It only assumes they are in the same (flat) address space. Put a gigabyte between them if you want.

If I had used `uintptr_t` instead of `ssize_t`, I think it's even compliant as far as wraparound goes.

edit: Note I changed the code to use uintptr_t

Reply on news.ycombinator.com