You are mistaken (as is _delirium). Pointers to arrays are fundamental to how multi-dimensional arrays are implemented in C, and this question is designed to test your understanding of them. (It is most certainly not about a fancy way of getting a pointer to the first element after the array, since this pointer has a completely different type.)

Multidimensional arrays are arrays of arrays, not arrays of pointers to arrays (as in Java). Therefore when manipulating, say, rows of a 2-dimensional array you are dealing with pointers to arrays like &x in this example.

It's not an every-day thing but it does come up, and in some specialised fields no doubt it is very common.

> (It is most certainly not about a fancy way of getting a pointer to the first element after the array, since this pointer has a completely different type.)

Have to be careful there. Going more than one after the end of the array is undefined (see 6.17):

http://c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=aryptr

Actually, that whole FAQ should be of interest to anyone who liked this article. No matter how many times I read through it, I seem to find something new.

I use it all the time in network and graphic programming, but I name the variables to state the fact. It's like a poor man's struct; sometimes you are doing say, some kind of packet analysis and you have some really convoluted spec to work off of. You could either formalize it in a bunch of headers and try to synthesize the structure of it or you can use tricks like this in order to parse it nicely.

In graphics programming, or more specifically, file format programming, sometimes I have to parse through, or generate a colortable and then go through a bunch of serialized data and transform that into a buffer where I have something like coordinate[x][y]{[z]}.{rgb/cmyk/yuv/hsv/rgba/bgr...} and I have a bunch of unions and structs; having char * data[3] as my payload and then being able to offset around into it is fantastically convenient, especially when trying to apply kernels or do transformations over the entire space.

The code is far more readable at the lower level manipulation with this kind of stuff.

And when you say 'Well I use OTS solutions for graphics' and I say "I do too, when I can. But when I can't, it's nice to be able to express what I need to do effeciently"

Same here. For the cases where you really do want to find the first memory address past the end of the array (if you're doing some hackish memory management, probably), I think x + sizeof(x) is more idiomatic than &x+1, because it avoids that particular arrays-are-almost-pointers weirdness in favor of regular pointer arithmetic.

Though I used to program a lot of C, I'm not a C wizard by a longshot, so I might be wrong. Are there cases where using expressions based on &x, where x is an array name, is idiomatic C?

edit: Stupid mistake, see cygx's reply (sizeof(x) gives the size of the array x in bytes, not in elements).

The idiomatic way to get a pointer to one past the end of an array x with element-type foo is

    x + sizeof x / sizeof *x

which is equivalent to

    (foo *)((char *)x + sizeof x)

whereas

    x + sizeof x

is equivalent to

    (foo *)((char *)x + sizeof (foo) * sizeof x))

The expression

    &x + 1

is not idiomatic as it has the type pointer-to-array-of-foo instead of pointer-to-foo.

As to your final question: Parameter declarations discard the size of array types - they are actually pointer-declarations in disguise.

To enforce a fixed array size, you need to declare a parameter of type pointer-to-array, eg

    void bar(int (*arg)[42]);

which you'd have to call like this:

    int x[42] = { 0 };
    bar(&x);

You can also get the "correct" type (type of &x[0]) by using:

  *(&x + 1)

I would be hard-pressed to call that idiomatic, however.

Agreed - but I have had code just like this come up as an interview question.