Hacker News Reader

Comment by jerrre | Hacker News Reader

isn't it guaranteed that is points sizeof(int) bytes higher than the address of b?

Whether something useful is behind that address is another question

There's a guarantee relative to the address of b. But there's no guarantee about the relative addresses of a and b themselves, i.e. where they are placed in automatic storage. So even setting aside the idea of optimizing the test away at compile time, there's no guarantee that the comparison result will be a specific value. a could be above or below b, and they are not necessarily adjacent objects.

From the C11 spec quoted in the article

> If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

So although most implementations might produce an address that's relative to b, that's not actually guaranteed by the spec unless it's `&b + 1`.

... which it is in the program under discussion. Again, the address which has no guarantee relative to the address of b or the value of q is the address of a.

From reading the spec it seems that is undefined behaviour for anything other than `&b + 1`. That is one past the end of b is fine but not `&b + 2` etc.

I wonder why someone decided that accessing "one past the end" should be fine

It's explained in the addendum to the article.

thanks

Short answer: so you can walk a pointer down the elements of an array without having to have weird code to deal with the end.

Depending on your architecture and compiler it could be that everything is 128 bit aligned, so you would had "empty holes" in your memory layout. (For example some dsp's)

I don't think that address of anything even has to be a positive number, according to the C standard.

Reply on news.ycombinator.com