REDIM, TYPE, and STRING Woes

[bplus]

Oh yes, one more thing. UDT's have never been fixed for saving to file variable length strings.

So if you save to file a UDT it must be like the old days with fixed string lengths only!!!

[bplus]

I've run into trouble using UDT's when I assume after a ReDim _Preserve that the new values are 0 or "" for numbers or strings.

Supposedly the numbers and fixed strings were fixed according to Luke if I recall but variable length strings had to initilized to "" otherwise they pick up garbage from the string pointers to uncleared meomory, something like that.

@TerryRichie could it be possible you were assuming new variable length strings were "" after a ReDim _Preserve ?

Perhaps also, whatever was fixed back when Luke checked it became unfixed with all the updates made since, like with assumed 0 of new integers created with ReDim _preserve?

I will write some test code...

I just posted a controller library in the library section. If you change the "Name AS STRING * 20" in "TYPE TYPE__SLOT" to "Name AS STRING" in the CONTROLLER.BI file you'll see the errors start to happen.

I scanned through code to see if you were either trying to do math on an assumed zeroed initialized variable or trying to save to file... couldn't even find the Type declaration, let alone seeing what you were doing with it. Sorry, too complicated for my patience today.

Udate: OK found it in downloaded zip line 710 of BI but @TerryRichie you know better than I what you are doing with the Type items.

[DSMan195276]

Oh yes, one more thing. UDT's have never been fixed for saving to file variable length strings.

So if you save to file a UDT it must be like the old days with fixed string lengths only!!!

Another clarification This isn't really a bug, it's not supported and unlikely to ever be supported since it's not clear how to make it work in a sane way.



As for the bug with Redim, I have it figured out. Basically what's going on is that with a normal Redim _Preserve the new memory (if any) is supposed to get zero'd, but when a Type contains a variable-length String that logic gets left out. We do already have logic to initialize all the new variable-length strings, so you should find the variable-length strings work and are always empty, but anything else in the Type will potentially contain garbage. I think this should be relatively easy to fix, I'll make a GitHub issue for it.

[SMcNeill]

Oh yes, one more thing. UDT's have never been fixed for saving to file variable length strings.

So if you save to file a UDT it must be like the old days with fixed string lengths only!!!

Another clarification This isn't really a bug, it's not supported and unlikely to ever be supported since it's not clear how to make it work in a sane way.



As for the bug with Redim, I have it figured out. Basically what's going on is that with a normal Redim _Preserve the new memory (if any) is supposed to get zero'd, but when a Type contains a variable-length String that logic gets left out. We do already have logic to initialize all the new variable-length strings, so you should find the variable-length strings work and are always empty, but anything else in the Type will potentially contain garbage. I think this should be relatively easy to fix, I'll make a GitHub issue for it.

Save to a second file (say *.vlsd for variable length string data) and only have the main file store offset + size.  

[DSMan195276]

Save to a second file (say *.vlsd for variable length string data) and only have the main file store offset + size.  

I don't personally consider that a viable fix because writing UDTs to a file shouldn't result in other files being created IMO it just creates too many potential problems. Storing them all in a single file also has separate issues because any reorganization of them would require modifying all the `offset + size` entries, and we don't know where they all are.


The GitHub issue for the redim thing is here.

[Kernelpanic]

In the present case, the meta command "$Dynamic" should/could help. The $Dynamic metacommand is a compiler switch that causes the compiler to not reserve fixed memory space for arrays during compilation.
The storage space is only requested at runtime; see the thread about static and dynamic arrays.

Meta commands are to be specified as comments!

I tried it once. . . but I would have to kneel in too hard now. 

[DSMan195276]

In the present case, the meta command "$Dynamic" should/could help. The $Dynamic metacommand is a compiler switch that causes the compiler to not reserve fixed memory space for arrays during compilation.
The storage space is only requested at runtime; see the thread about static and dynamic arrays.

In QB64 the $Dynamic metacommand doesn't actually do much. Both static and dynamic arrays are allocated at runtime, but static arrays have a flag set on them that prevents `ReDim` from working (it errors instead) and makes a handful of commands work slightly differently. When you use $Dynamic this flag isn't set so arrays created with `Dim` are treated the same as those created with `ReDim`.