Well, to be fair, it's not really a "problem" in C/C++ because pointers are arrays and arrays are pointers. That's why you can say 5[array] instead of array[5], if you want to be weird about it. The subscript operator is just a bit of convenient syntactic sugar. (And, for size information, you should also really never use sizeof() on an array. It's the closest to undefined behaviour you can get without actually being undefined behaviour. Personally, I don't think it should even be allowed, but there are legacy reasons for keeping it around, and frankly most compiler vendors would probably keep it as undefined behaviour even if the standard was changed.)
Good to know about that offset shortcut in gm-editor, though. I've seen it in the help page, but there was nothing that indicated what that was supposed to do, and I haven't come across a bare array anywhere else in any of the data structures dfhack exposes, so I haven't had an opportunity to experiment with it. Maybe adding a little note to the help page to clarify that it's for indexing bare arrays would be useful?
But, just out of curiosity, has it been determined that that particular variable is actually a bare array? Is it possible that that's a vector and nobody's noticed yet? I mean, everywhere else that I've seen, vectors are used, even in places where you could legitimately get away with even a statically-sized array, like the unit attributes and personality traits.
Short answer: no this can't be vector.
Long answer:
We mostly have the layouts from disassembly (and by we i mean other smarter people). This naked array is stored as an simple pointer (thing void* because in assembly every pointer is void*). Only the accessing code is reading e.g. by byte and checking nearby word or byte to stop or not the iteration. The vector on the other hand is totally different. It has three pointers. Each read is usually prefixed by size check which is read two pointers and shift/div/etc to figure out the item count, then compare to imput and sometimes jmp to exception or just jump to ret 0 part.
Statically sized arrays are also different thing. It's just like having a struct with N fields (e.g. {int x,y,z} is same as {int p[3]} but not {int* p} or {int p[] (is this valid at all?)}) So it looks totally different and the resulting size of struct is way bigger.
Then there is a HUGE magical thing that is lua wrapper. At the start i tried writing one but then angavrilov wrote the whole thing. There are some limitations like - you can't interpose vmethods from lua as it requires compiled code to replace the original (or doing automatic wrapper for EACH VMETHOD FOR ALL CLASSES - would be slow like hell) or like lua does not have "please list out all vmethods of this object with arguments" because nobody did need this bad enough to implement. Or in this case size for T* arrays. Although there are very few of them, and you could write out special handling for each of them - it's simpler to understand what is happening and have small snipped that does the same.
