NewsForumsCodeLogsGallerySpecsSearch

Function in method bug

Archives Forums/BlitzMax Bug Reports/Function in method bug

JoshK(Posted 2007) [#1]
Type thing

	Field v#=99
	
	Method do()
	
		func()
	
		Function func()
			Notify v
		EndFunction
	
	EndMethod
	

EndType


t:thing=New thing
t.do()



H&K(Posted 2007) [#2]
Type thing

	Field v#=99
	
	Method do()
	
		func(Self)
	
		Function func(ASelf:thing)
			Notify Aself.v
		EndFunction
	
	EndMethod
	

EndType


t:thing=New thing
t.do()



marksibly(Posted 2007) [#3]
Hi,

The compiler should be generating an error here, but basically you can't do this - inner functions cannot access the fields/locals of outer scopes.


Grey Alien(Posted 2007) [#4]
yeah I tried this a while back. It's a no go (at the moment, fingers crossed). I used to use this technique a lot in Delphi.


JoshK(Posted 2007) [#5]
I don't mind one way or another, but it would help if the compiler generated an error. This was causing some random crashes before I figured out what was wrong.


ziggy(Posted 2007) [#6]
It could, at least, throw a warning when nesting a function in a method. Nesting a function in a function does not produce this bug. I supose it is to the lose of instance context on functions.

I'm surprised that the BlitzMax compiler never produce warnings.


Lobby(Posted 2011) [#7]
Didn't anyone fix this bug yet? It seems to be still there -.-


Noobody(Posted 2011) [#8]
Oh wow, I stumbled upon the same bug a few days ago. My program kept crashing in random places inside an inner function. After a while I had a hunch that it was related to a member access, so I passed it as a parameter instead, after which the code worked as expected.

I'm very surprised and slightly irritated to find that this is not only a known bug, but that the corresponding bug report is over 4 years old. I'm not demanding access to members in inner functions, but I think a compiler error instead of broken executables is not too much to ask.


H&K(Posted 2011) [#9]
Both my example and Joshs example work on my computer. Im not saying it IS fixed, but to be clear do the two examples work?


Noobody(Posted 2011) [#10]
JoshK's example doesn't work both on my desktop and on my laptop (both running the latest version of BMax). The application doesn't crash in this case, but outputs a bogus value (it should be 99).

Your example of course works because it bypasses the problem ;) But the bug is still there.

Basically what happens is that the inner function can't access the members of the instance, because BMax doesn't pass the instance to the function (which it does for methods). At the same time, the BMax compiler still thinks that member access is valid, since the access still happens "inside" a method. What it should do is either implicitly pass the instance to the function or generate a compiler error if you try to access members from an inner function.

What's interesting is that if you pass the object instance to the function manually, member access works again, even though you don't explicitly access the passed object's members (like in your example). Consider this: 
Type thing

	Field v#=99
	
	Method do()
	
		func(Self)
	
		Function func(This:thing)
			Notify v
		EndFunction
	
	EndMethod
	

EndType


t:thing=New thing
t.do()



H&K(Posted 2011) [#11]
Well, for whatever reason Joshs Example works on my desktop. Its multi core, BUT I dont think I rebuilt for multi core

Last edited 2011


The_Nici(Posted 2011) [#12]
The wrong value is only returned when compiled in release mode, not in debug mode.


H&K(Posted 2011) [#13]
Ok, that explains that.

But to clarify what is it we are claiming is the bug? The fact it doesnt work (Which it shouldnt) or the fact the compiler STILL allows us to do it?


Noobody(Posted 2011) [#14]
The fact that the compiler does not complain about a piece of code that is illegal and generates a broken executable instead

Either the code is valid or the compiler complains - everything else is considered a bug in the compiler.