Array addressing failing using 3 dim array of ints. Any idea why this would fail? It just doesn't enter the value. I can manually enter it in debug, but programatically it fails.

[Robmar]

#define VBLOCKENTRIES 22
int16_t indexVDial = 0, ixVBFree = 0;
 
int16_t blocksSet[2][VBLOCKENTRIES][4];
 
blocksSet[indexVDial][ixVBFree][1] = 0x1000;   / Fails to write to array

[KnarfB]

May depend on the index values which are not shown in your code sample.

Anyway, 123123 is not an int16_t

hth

KnarfB

[Tesla DeLorean]

Hard to know dimensions / size here, or index values. Could get quite large, probably would avoid as a local/auto variable.

Provide more context.

[Robmar]

Index values given, it isn't addressing the memory correctly, so I was wondering if there is an issue with 3 dimensional arrays?

[Robmar]

True, it's reasonably small though int16_t[2][22][4], around 350 bytes.

It just doesn't write or read the values, I could manually set them in debug, but it was as if it just ignored the C code. Looking at the asm it looked too short to index correctly, just wondered if there was a known limitation with arrays with over 2 dimensions.

[KnarfB]

Never heard of such a limitation. Is the result used in the code? Could the assigment be optimized away?

[Robmar]

Yes it's used, I change from a 3D array to two 2D arrays, using the same indices, and it works correctly. [Table 0/1][Entry 0-21][0-4 int16 data] just fails to work at all. Weirdly in debug I can hover the cursor over the code line to set a value, and set it in the pop-up window, but it ignores the code line being executed:

entries[0][0][0] = 123; and nothing is written to the first table, first entry first int16

[Tesla DeLorean]

Odd, perhaps there's a bug in the GNU/GCC compiler.

Look at the assembler generated at different optimization settings.​