Does anyone else experience issues with free radical global variables?

[markyrocks]

 

Edit I'll leave this here as a lesson for others but i believe this is resolved.

 

I swear idk if i'm losing my mind if I'm not I'm about to .  This has literally happened to me at least twice that i know of and probably more bc I've gone down this rabbits hole seemingly so many times....

So I'm working on a script that exclusively contains functions... theres like maybe 10 or less global variables and i definitely give them unique names.  I try to keep the global variables down to the minimum but I don't explicitly declare every variables scope even though i'm about to start bc i've found on at least 2 different occasions that i've declared a variable inside a function, and may or may not have even called the function and it has somehow managed to turn itself into a global variable and then i've reused the variable name as i tend to do sometimes.  Then i'll be testing a different function that may not even involve the other function being called and then i'll end up with a variable spontaneously changing causing me to believe that theres an issue with the logic of what i'm trying to accomplish and i don't figure out the issue until i go through and check every variable's value line by line to see what the heck is happening.  Now i'm working with one script included in another and i'm afraid i have all kinds a free range radical variables floating around.... 

I swear i feel like alice bc i'm pretty good at coding in c++ and i feel like i'm halfway decent with autoit but i swear i feel like the system is fighting against me sometimes.  The only thing that i can understand is either making a global variable equal to a local in certain circumstances causes the local to remain persistent as if the pointer is being copied and not an actual copy either that or i'm having a recursion issue where i'll do something as an error check to prevent a function from failing like

func aFunc()
if "something doesn't happen" then return aFunc()

endfunc

 but if i was getting stuck in an endless loop i'd know it, that and in a situation like the above the function doesn't jump to another function it just runs until its done and jumps back to the main.

there maybe other small helper functions inside of that function but again they're all one and dones.  Maybe part of the issue is that i'm testing from globlal and not a main function.... but still the one thing shouldn't really affect the other.  I can't for the life of me wrap my mind around it.

 

Anyone experienced this is the past? I'm assuming that's part of the reason AutoItSetOption("MustDeclareVars", 1)  exists.... freaking crazy.  I've even had $x turn global and that's just a generic variable that i use mainly in for loops... is it possible that a variable declared inside of a for loop turned global?  I just know in c++ come hell or high water no matter what i do if i declare a variable inside of a scope that's it once that scope has exited its dead

;if you do something like

    if(1){
    int a=3;
    };<~~~~~~~~if you attempt to access int a after here.... its dead

 

this is a specific example of a variable that spontaneously changed on me and i have a bunch of crap commented out bc i spent so much time jerking around trying to figure out what happened

 

block was probably a variable of type pointer.  maybe that's the issue.  I had previously sought clarification on what that function was for and how to use it.  I was under the impression that the point was to turn a string into a variable of type pointer to be used in dll calls or dllstruct manipulation.  I havn't really experimented with it too much but i highly doubt that the point is to turn one variable into a pointer towards another .... i'd actually be pleasantly surprised if it did but I had also previously asked about making an alias in autoit with limited responses.

setting a variable to type pointer may make it persistent.  like in this case it might be why my $x turned into a free radical?   

 

 

Edited November 19, 2020 by markyrocks

[jchd]

No, AutoIt variables' scope doesn't change under your feet, never. Nothing like what you try hard to vaguely describe happens, ever.

You may need to realize that there is no block scope in AutoIt: anything declared in a control structure (If, Do, While, For) remains live after the end of said structure, retaining the scope in effect at (explicit or implicit) declaration time. There is no file scope either (unfortunately).

A variable is either global or local to a function.

[GokAy]

Hey,

Considering I have been using AutoIt for 1.5 months tops, and most certainly don't have enough experience with respect to you or many others lurking the forums, I never had any such issues. However, I also always use AutoItSetOption("MustDeclareVars", 1).

It is a habit from VBA. Even though it is not required, it makes you catch errors faster. And considered better coding practice by most.

Just my thoughts.  

[JockoDundee]

2 hours ago, markyrocks said:

The only thing that i can understand is either making a global variable equal to a local in certain circumstances causes the local to remain persistent

Are you aware that that sometimes Locals are really Globals?  It’s really kinda strange.

Global $aGlobal=1

Local $aGlobalAlso=2

$aGlobalAsWell=3

Func AFunc()

   Local $aLocal=1

   $aAlsoLocal=2

EndFunc

 

[markyrocks]

41 minutes ago, JockoDundee said:

Are you aware that that sometimes Locals are really Globals?  It’s really kinda strange.

Global $aGlobal=1

Local $aGlobalAlso=2

$aGlobalAsWell=3

Func AFunc()

   Local $aLocal=1

   $aAlsoLocal=2

EndFunc

 

anything declared outside of a function whether it be declared local or global is always global.  I'm well familiar with the intricacies thats why its so confusing.  I'm just going to have to declare everything bc i know i'm not that out of whack

[markyrocks]

2 hours ago, jchd said:

No, AutoIt variables' scope doesn't change under your feet, never. Nothing like what you try hard to vaguely describe happens, ever.

You may need to realize that there is no block scope in AutoIt: anything declared in a control structure (If, Do, While, For) remains live after the end of said structure, retaining the scope in effect at (explicit or implicit) declaration time. There is no file scope either (unfortunately).

A variable is either global or local to a function.

I'm telling you its the damnedest thing.  I watched it happen b4 my very eyes.  I think my issue is with using dim and redim bc apparently it has kind of a side effect. Which allows autoit some discretion ...this is what the documentation about what scope to give it .   "Using Dim will declare a variable and satisfy the AutoItSetOption just mentioned, but will let AutoIt scope the variable using the default settings as described above" ... thats not really explicit. I'm telling you I traced the variable fom begining of the function then when it was sent outside the function and returned the value changed as if it grabbed a global default value and returned it even thought the function wasn't byref or even changed the variable at all.  I'm not crazy and my logic is usually pretty on point.  Normally when I have big problems is when theres some kinda undefined behavior attached to the issue where something is either intermittently working or  reading garbage data from a straggling pointer.  Which i realize shouldn't happen.  Its amazing after i explicitly declared everything, what i was working on was in short order fixed and optimized!!  I wish i would of made a copy of the state of brokenness just to post it.  I even noticed there was a place where i didn't have the local variable declared and that might have been one reason that autoit was like O this variable is dim over here and over there its not declared so it must be a global.  I have no idea that's why i'm saying it was so strange...

[Melba23]

markyrocks,

I am with jchd on this one - I have never seen AutoIt change the scope of a variable behind my back. So unless you can provide a reproducer script (preferably short and to the point) I feel no requirement to even investigate further.

M23

[Nine]

Just my 2 cents.  Like M23, I never ever seen a change of scope.  But also remember there is a third type of scope (sort of).  Static variables are somewhat in between Global and Local.

[jchd]

Static is rather an attribute of a variable, whatever scope it has.

[JockoDundee]

9 minutes ago, jchd said:

Static is rather an attribute of a variable, whatever scope it has.

Scope and persistence are both equally defining attributes of a variable, Autoit’s nomenclature notwithstanding.

[Nine]

I do try not to get caught up in the flowers of the carpet 

[markyrocks]

9 hours ago, Melba23 said:

markyrocks,

I am with jchd on this one - I have never seen AutoIt change the scope of a variable behind my back. So unless you can provide a reproducer script (preferably short and to the point) I feel no requirement to even investigate further.

M23

 

I'm sure its something I did as a result of recycling variable names and using them in global tests.  I need to start running all tests in a main function and just call the function.   

I was probably delirious when this happened.   Lately I've been coding for 12-16 hrs at a clip.  I've started wearing sunglasses while on the computer bc my eyeballs are burning lol. 

I've learned the above lesson the hard way.  Usually when I'm writing c++ I have zero global variables so this isn't ever an issue.   The above is just a bad habit that has cost me hrs of my life.

I will say that the above issue may have been a result of changing a variable b4 a recursive control path fork and it took the recursive path and changed again.   

func afunc($a)
    $size=10
    $a+=$size
    If "something" then afunc($a)
    ; wa waaa waaaaaaaa

Edited November 19, 2020 by markyrocks

[JockoDundee]

16 hours ago, markyrocks said:

I'm telling you I traced the variable fom begining of the function then when it was sent outside the function and returned the value changed as if it grabbed a global default value and returned it even thought the function wasn't byref or even changed the variable at all.

What did you use to trace it with?

[markyrocks]

6 minutes ago, JockoDundee said:

What did you use to trace it with?

Msgbox's and console writes.  How do you troubleshoot? 

[JockoDundee]

25 minutes ago, markyrocks said:

Msgbox's and console writes.  How do you troubleshoot? 

Oh, usually the same as you.  Though there are interactive debuggers for autoit out there that let you do a real trace and set breakpoints etc.

I ask cuz I’m trying to imagine exactly what you saw that caused you to believe that variable transmutation was occurring.

So, when you say

16 hours ago, markyrocks said:

I'm telling you I traced the variable fom begining of the function then when it was sent outside the function and returned the value changed as if it grabbed a global default value and returned it even thought the function wasn't byref or even changed the variable at all. 

are you saying that you passed a purported local variable $alocal to another function, by value, that when the other function returned, $alocal was changed to the same value of some existing global value with the same name? 

Every time? How did you fix it?  Can you break it again?
 

 

[markyrocks]

1 hour ago, JockoDundee said:

Oh, usually the same as you.  Though there are interactive debuggers for autoit out there that let you do a real trace and set breakpoints etc.

I ask cuz I’m trying to imagine exactly what you saw that caused you to believe that variable transmutation was occurring.

So, when you say

are you saying that you passed a purported local variable $alocal to another function, by value, that when the other function returned, $alocal was changed to the same value of some existing global value with the same name? 

Every time? How did you fix it?  Can you break it again?
 

 

 

lol no active debugger.  usually if i have issues i'll rethink the original strategy to accomplish what i'm trying to do and rewrite the whole function.  The first iteration is usually overblown clunky unoptimized ect.  Then once i have the logic down pact like infallible, if i'm still having issues i'll go line by line and check the values of every variable.  i watched it change bc i had a msgbox b4 a function call and after in a function and watched it change.  here's an example of something that was blowing my mind.... this may have even been the original issue.  I can't even remember.

so imagine you have a script with 50 functions in it..... 

$b=block_allocate(13);<~~~~~~~~~~using this as a part of testing in global space....
$bb=block_allocate(11)
$c=block_copy($bb)
$e=block_copy_destroy($bb)



;and then having something like this buried 50 functions down and not understanding why the test is crapping the bed...

func block_copy($bPointer) ;##internal##
    $size=int(block_size($bPointer))

    $new=block_allocate($size)

    $b=$bPointer
    for $x=$new to $size+$new
        _Mem_Write($x,_Mem_Read($b))
        $b+=1
    Next
    Return $new
EndFunc

 

the way you fix is don't do anything in global space.  put everything in a _main(){ }.  Its kinda ironic that i'll be making a script with everything wrapped in functions and what kicks my ass is the testing itself... too funny.  

 

what i'm attempting do is create a big array thats like a memory pool and then allocate chunks of it when needed and daisy chain the blocks together by storing a pointer to the next block in the chain at the end of the readable memory.  I thought i had the basics of what i wanted to do down pretty well but then i started having all these issues and went back to the drawing board and then ran into more issues.  I've rewritten the foundation of this thing at least 3 times... I'm pretty sure that the foundation can't get much better, well that's not entirely true bc the "pool" has too many columns than i need bc i wasn't sure exactly how i wanted the storage system of the new data type that i'm after to work exactly....so i had extra colomns to store various bits of information for testing purposes but now that the foundation is secure i can cut the fat even further and eliminate some of the useless columns.  maybe it will be useful like that.  Maybe i'll keep it that way and instead of making the data type longer via another block i'll make it like a sideways heap.  that stores the pointers to the blocks that contain the pointers to the data itself.  Still working on it. 

 

 

Edited November 20, 2020 by markyrocks