[fpc-devel] QueryInterface on linux/i386 - adding 'in' parameter type?

[Michael Van Canneyt]

On Sat, 28 Aug 2010, Joost van der Sluis wrote:

> Hi all,
>
> The safecall calling convention is now implemented for i386/linux in
> fpc-trunk. The next step to get XPCom working now is to update the
> QueryInterface (and AddRef and ReleaseRef) definitions in IInterface.
>
> Problem is that they are defined as 'stdcall' but to make them work on
> Linux/i386 that should be 'cdecl'. So that will change in the near
> future. (using an ifdef, so it's stdcall on windows, cdecl on all
> others)
> This will break backwards compatibility on non-windows systems for users
> who implement their own QueryInterface, AddRef and ReleaseRef methods!
> But it's easy fixable and the compiler will complain.
>
> The problem that then still remains is that the IID parameter of
> QueryInterface has to be passed by reference. Now it's defined as
> 'const' so it won't be passed by reference in Linux (cdecl).

What does stdcall calling convention currently do on non-windows platforms ?

Because if it is something we decided, it simply means that we should change
it's meaning to be identical to mwpascal: cdecl calling convention, and const
structs passed by reference. If I'm right, 'stdcall' currently
has no meaning on non-windows platforms other than the one we put on it.

It solves all your problems in one go, plus it makes writing header
translations a lot easier. (Pending the question of what the C compiler does
with const structured C parameters)

If that is not possible, then I think Marco's idea of a switch is best.
I see it as similar to the {$packrecords } directive: it doesn't change the
syntax or meaning (as Jonas fears), but does instruct the compiler how to 
handle things on a more low-level (in casu: assembler) scale.

I think that having to write
   {$ifdef windows}const{$else}constref{$endif} myarg: mytype
for possibly thousands of arguments in an interface description is simply not
an option.

Michael.