BUG DESCRIPTION:
----------------
In Scilab 5.5.2
===============
when implicitly extending the size of a struct array by specifying the value of a component at indices beyong the array size, all components of the new array set within the new array sizes but not targeted by the assignment are initialized with []:
-->clear s
-->s.t = "Test"
s =
t: "Test"
-->s(3).t = "Trial"
s =
3x1 struct array with fields:
t
-->s(2).t
ans =
[]
This was not fully satisfying, since an "undefined" component (of type==0) would have been expected instead, as for list():
-->L = list("Test",,%pi);
-->type(L(2))
ans =
0.
While we had:
-->struct("r",%pi,"b",,"t","Test") // undefined value for .b
!--error 10000
typeof: Wrong value for input argument #1: Defined variable expected.
at line 3 of function typeof called by :
at line 34 of function struct called by :
struct("r",%pi,"b",,"t","Test")
In Scilab 6.0.0:
===============
--> s = struct("r",%pi,"b",,"t","Test")
s =
r: [1x1 constant]
b: void <<< This is fine, more consistent with list() behavior
t: [1x1 string]
--> type(s.b)
ans =
0. <<< definitely OK
BUT when extrapolating an array, the situation got worse instead of improving:
-------------------------------
clear s
s.t = "Test";
s(4).t = %z
// So now we expect that s(2).t and s(3).t are undefined, or for the worst set to [] as in 5.5.2.
// Instead, we get now:
--> s.t
ans =
ans(1)
Test
ans(2)
z <<< ! NOK
ans(3)
z <<< ! NOK
ans(4)
z
This is the bug.
ERROR LOG:
----------
None. Wrong initialization.
HOW TO REPRODUCE THE BUG:
-------------------------
clear s
s.t = "Test";
s(3).t = %pi;
type(s(2).t)==0
OTHER INFORMATION:
------------------
Bug found when fixing the bug 15260 (also major)