Stack pointer validation for call function/method opcodes

[MiranDMC]

Can it backfire in any way? Plugin compiled in debug configuration throws similar exceptions\error messages when stack pointer is left modified.
Does it make sense to allow scripts in legacy mode to not pop after call?

[x87]

This is a very complicated area and I would better avoid making changes here. We should encourage people using new foreign function syntax in SB with proper calling convention and clearly defined arguments, and avoid dealing with raw commands like that.

[MiranDMC]

This is a very complicated area and I would better avoid making changes here. We should encourage people using new foreign function syntax in SB with proper calling convention and clearly defined arguments, and avoid dealing with raw commands like that.

Yes, but new syntax also relay on user specifying correct calling convention. As said module build in debug mode automatically throws exceptions when such scenario occurs.
I'm just not ASM fluent to the point to be absolute sure, there is not single case where exception from that rule occurs. Can you think of single case where modified stack pointer after return from call is intended behavior?

[x87]

No idea. Possibly not, but I can't guarantee.

Calling external code is a precise operation. You must do it right. This is not something we should correct.

[MiranDMC]

No idea. Possibly not, but I can't guarantee.

Calling external code is a precise operation. You must do it right. This is not something we should correct.

This is how the debug error itself looks:

Might be worth to read more about that (exact circumstances when it occurs) and reflect that behavior.
Topic for further investigation in future.

Feature like that would be beneficial. So far the error did not occurred for me, but I have another project where I mess with RenderWare and it sometimes crashes. Not sure if it could be caused by stack corruption somewhere.

[x87]

I was about to say after some thinking, maybe we can keep it and see if user would complain.

The error message in VS is much more helpful that what CLEO provides. Maybe we can use the exact wording + usual script info.

[MiranDMC]

I was about to say after some thinking, maybe we can keep it and see if user would complain.

The error message in VS is much more helpful that what CLEO provides. Maybe we can use the exact wording + usual script info.

Well the VS error message does not seem to be much more helpful. All the script user needs to know is the script command and information the "pop" argument was too small/big.

[MiranDMC]

Updated.