When decreasing the size of a multidimension array using REDIM PRESERVE, the number of array elements to be destroyed and their locations are not correct (this works for a 1D array).
For more information and test codes, see the 'REDIM PRESERVE does not destroy the right array elements of a multidimensional array -> memory leak' topic on the forum (in 'General'):
https://www.freebasic.net/forum/viewtopic.php?f=3&t=29713
By cons, when increasing the size of a multidimensional array using REDIM PRESERVE, the number of array elements to be constructed and their locations are correct.
In the example I gave below, there is an error in both the number and location of elements to be destroyed.
Yet the rule is simple:
For a dynamic array, if the total number of elements required by REDIM PRESERVE is reduced by "N" elements compared to the total number of existing elements, the last "N" elements of the existing array must be destroyed before reallocating the memory for the new array.
Then, the only difficulty is to correctly calculate the address zone of the elements to be destroyed:
base_ptr, uinteger:size, uinteger:element_len).Last element address:
base_ptr + size - element_lenLast edit: fxm (freebasic.net) 2021-11-27
Simple example to highlight the bug
In the following code using a UDT with destructor as data-type for the 2D array, and for the transition:
Redim array(3, 4) -> Redim Preserve array(2, 3)we see that only 5 instances are destroyed by 'REDIM PRESERVE' and the wrong ones (not the last 8 instances of the array before resizing):
(fbc 32-bit)
Even for a transition that must keep the data with their values at the right addresses:
Redim array(4, 5) -> Redim Preserve array(3, 5)the destroyed instances by 'REDIM PRESERVE' are not the correct instances:
(fbc 32-bit)
Last edit: fxm (freebasic.net) 2021-11-28
Bug of element destruction for a 2D array (deduced from all my tests):
Fixed in fbc 1.09.0
commit [7fa0729f10265f43d4edbde4d53cb18ed78d1bd0]
Related
Commit: [7fa072]