Hi Manuel,
Yes, I know that cam_xyz[] would have to be declared
differently for *(cam_xyz + (i)*3 + (j)) to work, but it's
all the same at the hardware level.
If arrays are no longer pointers, but some sort of
abstract array-type, does ISO C allow them to be cast back
into pointers? Something like:
((double *)(cam_xyz[0]))[j] = table[i].trans[j] / 10000.0;
Dave Coffin 2/27/2015
On Fri, Feb 27, 2015 at 09:08:50PM +0100, Manuel López-Ibáñez wrote:
> On 27 February 2015 at 20:02, <dcoffin@xxxxxxxxxxxxxxxxxx> wrote:
> > Manuel,
> >
> > There is no "undefined behavior" here. K&R defined it
> > very clearly: Arrays are pointers, and square brackets are
> > syntactic sugar for pointer arithmetic and dereferencing:
> >
> > cam_xyz[i][j] vs. *(cam_xyz + (i)*3 + (j))
>
> Unfortunately, this is simply not true for ISO C, which is the
> language that most compilers implement nowadays. And it is easy to
> check for yourself:
>
> test.c:445:27: error: incompatible types when assigning to type
> 'double[3]' from type 'double'
> *(cam_xyz + (0)*3 + (j)) = table[i].trans[j] / 10000.0;
> ^
>
> See also the first answer to
> http://stackoverflow.com/questions/25139579/2d-array-indexing-undefined-behavior,
> which seems correct, AFAIU.
>
> Neither can you do: **(cam_xyz + (0)*3 + (j)), because cam_xyz has
> type 'double (*)[3]' thus **(cam_xyz + 2) is referencing
> cam_xyz[2][0].
>
> Cheers,
>
> Manuel.
