4

In C18 we have:

§ 6.5.9p10

Two pointers compare equal if and only if both are null pointers, both are pointers to the same object(including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space.

So for int a[4][2] = {{1, 2}, {3, 4}, {5, 6}, {7, 8}}, we can have a[1] == a[0] + 2.

Can that by consequence guarantee that *(a[1]) == *(a[0] + 2)?

oblitum
  • 11,380
  • 6
  • 54
  • 120

1 Answers1

6

It is not allowed to dereference such a pointer, even if it compares equal to another valid pointer.

Section 6.5.6p8 regarding the + operator states:

When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integer expression. In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i+n-th and i−n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object,the expression (Q)-1 points to the last element of the array object. 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. If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated

On a related note, some compilers have the concept of pointer provenance, meaning it internally keeps track of the source of a pointer. A consequence of this is that if two unrelated variables are adjacent in memory, comparing the address of one to one-past the address of the other will always evaluate to false, even if the addresses are the same.

dbush
  • 205,898
  • 23
  • 218
  • 273
  • *"some compilers have the concept of pointer provenance"* Sounds interesting, can you tell more? Which compilers do that? – HolyBlackCat Aug 01 '20 at 18:10
  • 1
    @HolyBlackCat See [this question](https://stackoverflow.com/questions/45966762/can-an-equality-comparison-of-unrelated-pointers-evaluate-to-true) I posted a few years back. – dbush Aug 01 '20 at 18:11
  • Thanks for your answer. Do you happen to know how this is covered in C++? I avoided tagging it as C++ and quoting its standard because in general here users reprove C/C++ questions. I suppose it'll lead to the same conclusion maybe, but it seems quite less explicit on this. – oblitum Aug 01 '20 at 18:16
  • @pepper_chico In C++, `*` expects its argument to point to an object or function, so pointers past the end don't fit. It is indeed less explicit than in C. – Language Lawyer Aug 01 '20 at 18:24
  • @LanguageLawyer I'm actually wondering whether it has the same pointer equality guarantee as in the illustration too, not only the dereference aspect (it's a corner case of one past the end). – oblitum Aug 01 '20 at 18:26
  • @pepper_chico To be TBH, I don't think that either C or C++ guarantee that for `T arr[N][M];`, `&arr[0][M]` will compare equal to `&arr[1][0]`. But maybe I'm reading the standards too pedantically. – Language Lawyer Aug 01 '20 at 18:30
  • @LanguageLawyer your expression is indeed UB, because you're doing (final) dereference prior to getting address for the comparison. I don't do this in the example. – oblitum Aug 01 '20 at 18:32
  • @pepper_chico That would actually be OK because `&arr[0][M]` is exactly the same as `&*(arr[0] + M)` and `&` immediately follow by `*` effectively cancel each other out as per 6.5.3.2p3 resulting in `arr[0] + M` – dbush Aug 01 '20 at 18:35
  • @pepper_chico In C, for `T arr[N];`, `&arr[N]` 100% is **not** UB. `E1[E2]` is equivalent to `*((E1) + (E2))`, i.e. `&arr[N]` is equivalent to `&*(arr + N)`, and the C standard says that if the operand of the `&` operator has the form `*E`, neither `&`, nor `*` are evaluated and the expression `&*E` is equivalent to `E`. – Language Lawyer Aug 01 '20 at 18:36
  • @LanguageLawyer all OK, but C++ doesn't permit that, sorry about the confusion. But as both question and answer here show, comparison is valid in C. So no point in doubting that for C? – oblitum Aug 01 '20 at 18:37
  • @pepper_chico I can rewrite w/o UB if you want: `arr[0] + M` and `arr[1] + 0`. And still I'm not 100% sure that these 2 pointers are guaranteed to compare equal by the Standard and it is not just a side effect of how pointers and their arithmetic is implemented in a typical implementation. – Language Lawyer Aug 01 '20 at 18:40
  • @LanguageLawyer I thought my quotation with emphasis would be explicit enough guarantee, in C. If you're now only talking about C++, then yeah, I don't have something direct like that to be so sure. – oblitum Aug 01 '20 at 18:46
  • @pepper_chico your emphasis just tells when pointers compare equal, but doesn't guarantee that `arr[1]` "happens to immediately follow" `arr[0]`. (No, I don't want to say that there can be padding "between" them). – Language Lawyer Aug 01 '20 at 18:48
  • @LanguageLawyer array elements are guaranteed to be contiguous (one adjacent to the other). I didn't see necessary to also quote that for the question. – oblitum Aug 01 '20 at 18:51
  • @pepper_chico _array elements are guaranteed to be contiguous_ And what does this **really** mean? I mean, how can this be observed from a C program? – Language Lawyer Aug 01 '20 at 19:01
  • @LanguageLawyer I think this side question is derailing the focus, maybe it's worth another SO question. – oblitum Aug 01 '20 at 19:09