7 ms·

Basically you have no guarantee where the pointer q is pointing to. Some compiler/static code analyzer will yell at you with this code.

jerrre 8y ago
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
- ChrisSD 8y ago
  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.
  - zubyak 8y ago
    I wonder why someone decided that accessing "one past the end" should be fine
    - jwilk 8y ago
      It's explained in the addendum to the article.
      - zubyak 8y ago
        thanks
    - mcguire 8y ago
      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.
    - deleted 8y ago
      [deleted]
- JdeBP 8y ago
  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.
  - ChrisSD 8y ago
    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`.
    - JdeBP 8y ago
      ... 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.
- golergka 8y ago
  I don't think that address of anything even has to be a positive number, according to the C standard.
- nuriaion 8y ago
  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)

jerrre 8y ago

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

ChrisSD 8y ago
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.
- zubyak 8y ago
  I wonder why someone decided that accessing "one past the end" should be fine
  - jwilk 8y ago
    It's explained in the addendum to the article.
    - zubyak 8y ago
      thanks
  - mcguire 8y ago
    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.
  - deleted 8y ago
    [deleted]
JdeBP 8y ago
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.
- ChrisSD 8y ago
  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`.
  - JdeBP 8y ago
    ... 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.
golergka 8y ago
I don't think that address of anything even has to be a positive number, according to the C standard.
nuriaion 8y ago
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)