Strange things are afoot at the Circle K

[TerryRitchie]

Lately I've been getting a few anomalous bugs in my code that are very hard to track down and I believe I know the reason.

I've never taken the time zeroize or clear string contents in newly created arrays or variables in BASIC because that seems to have always been done automagically since the days of BASIC 80. However QB64 seems to not be exhibiting the behavior any longer. This seems especially true for variables defined as _BYTE inside and outside of TYPE statements. (I use _BYTE for boolean TRUE(-1) and FALSE(0) flags).

Many times my "bugs" disappear when I take the time to zeroize the arrays and variables I create ... in other words I can't assume any longer that variables and strings will be set to 0 or null when newly created.

Has anyone else run across this behavior? When I have time I'll try to create some code that shows this happening.

[SMcNeill]

If you use _MEM commands, they don't clear/initialize memory, but DIM should. 

[TerryRitchie]

Yes, I knew about this behavior with _MEM from the extensive examples and tutorials on the subject you have provided over the years. And yes, I would also assume that DIM would clear/null newly created variables, that why I always DIM every variable I use in code.

It's just that lately routines I create to fire only when a variable is true (non-zero) are triggered without my code setting the variable. Now here's the strange part ... when I print the variable to see what's inside I'm presented with zero. However, for example, an IF statement will treat the variable as being non-zero. If I set the variable to zero manually upon it's creation the IF statement will then see the variable correctly.

It's strange behavior and I can't pin down or predict when/where it will happen in code. I do know though if I zeroize/null all variables before use this behavior seems to disappear in my code. Again, this seems to happen much more often with _BYTE declared variables.

[TerryRitchie]

No matter what I try to recreate this happening in my code I just can't seem to. The code below executes flawlessly every time. I can't seem to find the secret sauce that is causing this to happen to me.

Code: QB64: [Select]

1. TYPE ATYPE
2.     aByte AS _BYTE
3.     anInteger AS INTEGER
4.     aLong AS LONG
5. END TYPE
6.  
7. TYPE TEST
8.     aType AS ATYPE
9.     aByte AS _BYTE
10.     anInteger AS INTEGER
11.     aLong AS LONG
12. END TYPE
13.  
14. DIM Testing(10000) AS TEST
15. DIM c AS INTEGER
16.  
17. DO
18.     IF Testing(c).aType.aByte THEN PRINT c; Testing(c).aType.aByte
19.     IF Testing(c).aType.anInteger THEN PRINT c; Testing(c).aType.anInteger
20.     IF Testing(c).aType.aLong THEN PRINT c; Testing(c).aType.aLong
21.     IF Testing(c).aByte THEN PRINT c; Testing(c).aByte
22.     IF Testing(c).anInteger THEN PRINT c; Testing(c).anInteger
23.     IF Testing(c).aLong THEN PRINT c; Testing(c).aLong
24.     c = c + 1
25. LOOP UNTIL c > UBOUND(testing)
26.  

I'll keep trying to recreate the issue (for my own sanity) and if I find the correct situation that causes this for me I'll post it here.

[SMcNeill]

String support was recently added to TYPE.  Could it be affecting something?

TYPE whatever
     X AS _BYTE
     Y AS STRING
     Z AS _BYTE
END TYPE

Are you using types like the above and getting Glitches?

[bplus]

Type + REDIM _PRESERVE probably good time to zero out new sections. I definitely had code go South with this combo and fixed when zeroed out. But come to think, I don't remember clearing a new section under REDIM _PRESERVE, maybe it was just REDIM with a Type. I don't use Byte too often (Steve says it saves no more room anyway as I recall) so I think the problem was a Type with INTEGER, I was assuming would be 0 but wasn't (before v1.4).

[TerryRitchie]

The TYPEs I'm creating come in all sizes, from a few variables to as many as 50 or more, all of various declarations from _byte, to string, to long. Many of the TYPEs I create are also embedded with many other TYPE declarations. I'll add strings into the test code and see what happens.

I hoping this is just something anomalous to my coding style or perhaps even my system. However, I ran across this strangeness when creating Widescreen Asteroids but didn't think too much of it. Now it's happening to me again in my latest project and I posted to find out if anyone else had noticed this.

I'm also passing TYPEs between subs/functions so I have a few different scenarios to test and see if I can recreate this.

[TerryRitchie]

Type + REDIM _PRESERVE probably good time to zero out new sections. I definitely had code go South with this combo and fixed when zeroed out. But come to think, I don't remember clearing a new section under REDIM _PRESERVE, maybe it was just REDIM with a Type.

Ya, that's a good point. I'm using REDIM and _PRESERVE with many of these variables as well.

[bplus]

Cross posted I added an edit with more info above.

[TerryRitchie]

Is that correct? _BYTE uses the same amount of RAM as INTEGER? The only reason I'm using _BYTE is to minimize my program's footprint in RAM. I'll switch everything to INTEGER if this is the case.

[FellippeHeitor]

_BYTE uses a byte. It's _BIT that's troublesome and uses up much more than it lets us think.

[bplus]

_BYTE uses a byte. It's _BIT that's troublesome and uses up much more than it lets us think.

Opps! bit, byte sorry.

[FellippeHeitor]

Code: QB64: [Select]

1. DIM a AS _BYTE

The above results in:

Code: C++: [Select]

1. int8 *__BYTE_A=NULL;

Whereas:

Code: QB64: [Select]

1. DIM a AS _BIT

Results in

Code: C++: [Select]

1. int32 *__BIT1_A=NULL;

[FellippeHeitor]

Also, if variable is _BYTE, assigning it a value of 1 (as simply as a = 1), results in this C++ code:

Code: C++: [Select]

1.     *__BYTE_A= 1 ;

whereas doing the same with a _BIT variable results in this:

Code: C++: [Select]

1.     if ((*__BIT1_A= 1 )&1){
2.         *__BIT1_A|=-2;
3.         }else{
4.         *__BIT1_A&=1;
5.     }
6.  

[TerryRitchie]

_BYTE uses a byte. It's _BIT that's troublesome and uses up much more than it lets us think.

Thanks for the clarification and code examples.