Yeah but don't you find it curious, most curious, how the introduction variable length strings corrupts the integrity of Longs of other numeric type?
Not really. If I had to guess, the internal process is probably using some process like:
Find first element memory address.
Count total space of type.
Multiply space * array size.
Mem fill address, total size, 0’s...
Now, with the first element being a variable-length string, that’s NOT where the array starts; it’s a pointer to where that string is stored in memory. That could be the issue.
Or... total type size could be off. 2 * Variable STRING + 3 * LONG... What is the LEN(TYPE)? 12? 0? Something else? That can affect the mem fill...
I’d say it’s basically something related to the above that is causing the issue. The easiest way to initialize a variable/array to zero is just memfill m, m.offset, m.size, 0 — but how do you calculate those fill values?
When variable length strings are in use, you almost have to have a loop similar to:
FOR I = lbound TO ubound
t$(I) = “”
NEXT
Since TYPEs never handled variable lengths until recently, it makes sense that their fill routine went the quick and simple route of memfill, rather than a slower loop fill structure.