[fpc-devel]I suggest a new FPC feature

Jonas Maebe jonas at zeus.rug.ac.be
Fri Oct 12 13:49:24 CEST 2001

On vrijdag, oktober 12, 2001, at 01:32 , Pavel V. Ozerski wrote:

> The functionality is also not always the same: if inside "fpc stdcall" 
> procedure something will change
> these three registers, it will not always cause appliction crash 
> because they will be retored before return.
> Procedures/functions having default calling conventions and compiled 
> with FPC or procedures/functions
> declared as stdcall but compiled with Delphi are potentially more 
> dangerous. "FPC stdcall" is something
> middle between "Delphi stdcall" and safecall. I'm concordant with you, 
> the functionality under normal conditions
> is the same. But the situation with stdcall constructors demonstrates 
> that the difference can be important somewhere.

That procedures/functions with the default calling convention are 
incompatible between Delphi and FPC, is true. Not only due to the 
differences in register saving, but also due to differences in parameter 
passing (Delphi supports register parameters, FPC doesn't (yet)). I 
think that's exactly the reason why you can specify calling conventions.

However, when declaring them as stdcall, they should be compatible. 
Delphi should save ebx/esi/edi if they're modified (and I think 
assembler statements don't count, just like FPC's assembler parser, 
Delphi's parser probably also doesn't try to "understand" the assembler 

The fact that there are problems with stdcall constructors under FPC, is 
just that the popped esi at the end overwrites the pointer to the 
generated object (which is normally returned in esi) I think. So we 
should indeed reject cdecl/stdcall/... for constructors.


More information about the fpc-devel mailing list