Author Topic: Possible Variable-length strings in Types bugs  (Read 3899 times)

0 Members and 1 Guest are viewing this topic.

Offline Ophelius

  • Newbie
  • Posts: 15
    • View Profile
Possible Variable-length strings in Types bugs
« on: August 09, 2020, 01:31:01 pm »
There's definitely some internal bugs when it comes to those. Before I found out this feature was added, I had several Types for various objects, but any strings were put in separate arrays like this:

'All the following code is just for examples

REDIM SHARED Obj(0 TO n) AS ObjType
REDIM SHARED ObjText(0 TO n) AS STRING

Both arrays always had the same numbers of elements so it was easy to reference the strings for whatever objects I needed. This worked great and was better than trying to use fixed-length strings in Types.

But when I found out about variable-length strings added to Types, I added the strings to my Types like this in order to clean up my code:

Type ObjType
   a as integer
   b as integer
   Text as string
End Type

REDIM SHARED Obj(0 to n) AS ObjType

After I did this, my program became possessed, weird bugs would happen, some that were even different if I ran the program at another time, even though no code changed.
They appear to be related to the internal memory of how QB handles the strings in the Types.
The bugs seems to always happen in places when I would get the Len of the string -> LEN(Obj(id).Text). I checked and the function is returning the correct length in all my tests, so there's something more internal going on. There seems to be memory overlaps, causing random elements and objects to change their behavior because memory locations are being corrupted.

Another thing that might be affecting it is I have several dozens of objects, each being REDIMed _PRESERVEd when they were created/added to the array, maybe that has something to do with it.

So after scratching my head all day looking if it was my own code, I came to the conclusion that it wasn't my code and put my code back to what it was, putting the strings back in separate arrays. After I did that, my program became normal again working perfectly.

Sorry I can't be more specific, the bugs were really random and weird, but I can tell it's some internal memory problem.


Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: Possible Variable-length strings in Types bugs
« Reply #1 on: August 09, 2020, 02:08:46 pm »
We have found that you can't assume Types initialized to 0 or "" for strings, maybe your code is assuming this?

If you say DIM x you can count on x being 0 to start or DIM s as string you can count on s ="", not so with variables in defined types.

Oh, also with a REDIM PRESERVE expanding an array, don't assume all is 0 or "".
« Last Edit: August 09, 2020, 02:10:27 pm by bplus »

Offline Ophelius

  • Newbie
  • Posts: 15
    • View Profile
Re: Possible Variable-length strings in Types bugs
« Reply #2 on: August 09, 2020, 02:15:47 pm »
We have found that you can't assume Types initialized to 0 or "" for strings, maybe your code is assuming this?

If you say DIM x you can count on x being 0 to start or DIM s as string you can count on s ="", not so with variables in defined types.

Oh, also with a REDIM PRESERVE expanding an array, don't assume all is 0 or "".

There were places where I wasn't initializing the variables, I was assuming uninitialized Type variables would be 0 or "" like you said. That's probably why. But since I already reverted my code to what it was prior, I'll just keep what I have which works. Good to know for the future.Thanks
« Last Edit: August 09, 2020, 02:23:17 pm by Ophelius »

Offline luke

  • Administrator
  • Seasoned Forum Regular
  • Posts: 324
    • View Profile
Re: Possible Variable-length strings in Types bugs
« Reply #3 on: August 09, 2020, 07:49:53 pm »
I think something is off when it initialises the string descriptor, causing it to smear data over the other elements. Despite what bplus says you should be able to expect variables to always be initialised to 0/"" so it's definitely a problem.

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: Possible Variable-length strings in Types bugs
« Reply #4 on: August 09, 2020, 08:06:37 pm »
Quote
Despite what bplus says you should be able to expect variables to always be initialised to 0/""

Despite?

Bplus expected it and was sorely disappointed. ;(

This was discussed here at forum some time ago.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Possible Variable-length strings in Types bugs
« Reply #5 on: August 09, 2020, 08:18:33 pm »
Despite what bplus says you should be able to expect variables to always be initialised to 0/"" so it's definitely a problem.

Except with _MEMNEW.  Galleon never had mem blocks reset to null, so as to not add any overhead to them initializing.  Mem is for speed, and if you’re just going to fill your block as soon as you create it, it doesn’t matter if it’s been nulled or not.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!