This behavior is counterintuitive. You take a known working code, but it does not work.The problem is that this kind of details are not documented anywhere by Borland/Codegear/Embarcadero afaik, so it is very hard to get them all exactly the same from the start. And once you implement them differently in a shipping release and then change them afterwards, you will probably start breaking other working code (code that was written for FPC according to the behaviour implemented in FPC, possibly even in mode Delphi).
So yes, there are issues with nested procedures to be used on a more serious level. I would of thought the compiler would simply know the difference and not allow the inner actions of the pascal type frame to be accessible while doing this, but no, it just simply refuses to comply.That is incorrect. What happens is that Delphi passes the framepointer in a way that completely ingnores the calling convention. This in turn means that the routine can be used both with and without a framepointer parameter (including as a callback to something that doesn't know about nested routines, as long as you don't access any local variables from the local routine).
Basically the calling conventions are ignored..
Ultimately, I realized that the problem was in the automatically generated RET 4 statement at the end of the nested procedure.It turns out this bug is already fixed in the upcoming FPC 3.2.0 release.
Its about time you DEV's put your coffee cup down and make those fingers work on the keyboard!What's that supposed to mean? :o We are hard at work with FPC so please refrain from such comments.
Its about time you DEV's put your coffee cup down and make those fingers work on the keyboard!What's that supposed to mean? :o We are hard at work with FPC so please refrain from such comments.
btw not fixed
you will get an Runtime error 216 here with $CALLING PASCAL or STDCALL
if you uncomment the «ret» then works