2

In the following pointer to array,

int x[5] = {1};
int (*a)[5] = &x;

what implications and consequences can i have if i don't use & operator and do like this..

int x[5] = {1};
int (*a)[5] = x; //No & operator

Can anyone explain with some good example..

Armaan Saxena
  • 31
  • 4
  • 1
    Could you explain the expected effect and your understanding of the meaning of each of those code lines? – Yunnosch Apr 29 '18 at 18:58
  • 2
    Without checking the validity of the code above, both `x`'s have the same type and both `a`'s too, `x` and `&x` don't have the same type. So the code is fundamentally wrong. If you are not experiencing any difference, enable compiler warnings. – Iharob Al Asimi Apr 29 '18 at 18:58
  • Here am giving a link for your consideration. http://c-faq.com/aryptr/aryvsadr.html – Armaan Saxena Apr 30 '18 at 05:26
  • @FelixPalmen I phrased so as to keep the wrong/correct decision open. (Admittedly because even the first code looks a little strange to me.) What I wanted to achieve is the statement that it/both does compile without errors/warnings, even strict. And if not, the verbatim quote. – Yunnosch Apr 30 '18 at 07:14
  • Please state, for each version of the code, whether you can compile without errors or warnings, even if you use strictest warning output. – Yunnosch Apr 30 '18 at 07:16

1 Answers1

4

Well, the type would be wrong.

in your example, x would evaluate to an int *, a pointer to the first element of x. &x, on the other hand, evaluates to int (*)[5], a pointer to the whole array.

It's hard to come up with an example of this going wrong in practice, as an array starts with its first element by definition. But it's still wrong on a language level. Pointers can't be converted implicitly, with the one exception of void *. So, with your second example, the compiler should actually warn you (if it doesn't, add some flags, like for gcc use -std=c11 -Wall -Wextra -- or get a better compiler).

If you write the following instead:

int x[5] = {1};
int (*a)[5] = (int (*)[5])x;

it will work and should compile without warnings. Still, it's not the correct way to do it. Although in this specific case, the cast should always work as expected, you should in general avoid casting pointers in C. A pointer cast is a potential bug, so only do it when it's absolutely necessary and then double check the resulting code doesn't violate strict aliasing (look it up...).

Here, there's just no need for a cast -- write &x and you're fine.

  • 1
    I don't think it's a strict aliasing violation, it's just compilers are bound to complain even though everything happens to "fit" in the end in this case. – Petr Skocik Apr 29 '18 at 19:12
  • 1
    well, I added the word *potential* for a reason. It's meant as "all that could still go wrong" :) That said, I'm not sure you could construct a strict aliasing violation in this case myself. Let me think about it .... –  Apr 29 '18 at 19:13
  • @PSkocik added a bit of explanation, I hope it's ok. –  Apr 29 '18 at 19:24
  • 2
    It's ok to have differently typed pointers pointing at the same object. Accessing an object through a wrongly typed L-value is what's forbidden. In this case, there shouldn't ever be a problem. You can't assign to an array, only to one of it's members, so you need to deref the array pointer to get a ptr usable for access (actually an array that when used with further derefing decays to int*) and that int* will very legally alias with a directly obtained pointer to the first int of the same array. – Petr Skocik Apr 29 '18 at 19:50
  • @PSKocik Sure, without accessing the object, it's moot, and you can't access an array as a whole (which is kind of peculiar). Still I'm not sure your argumentation holds. With some pointer to struct, wouldn't it be an access of this struct object to write `x->foo[42]`? With the array, `(*x)[0]` would be a similar construct. Anyways, I'll edit the answer once again to just avoid this minefield. –  Apr 30 '18 at 06:07
  • I once asked about that here: https://stackoverflow.com/questions/42352681/strict-aliasing-and-overlay-inheritance . Please check the accepted answer. (Anyway, I already upvoted the 1st version of the answer.) – Petr Skocik Apr 30 '18 at 07:18
  • @PSkocik thanks, quite interesting. "*Most agree that the standard's definition of strict aliasing is too vague and needs improvement.*" <- indeed. So, as this question isn't directly about *strict aliasing*, I'll just leave the answer as it is now, containing only a hint. –  Apr 30 '18 at 07:22