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

[Joost van der Sluis]

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).

Now I see three options: pass all records with a size bigger then the
register-size by reference for all cdecl-params which are defined as
'const'. The same happens for stdcall parameters on Windows and this is
suggested before by some people. This should not lead to any backwards
compatibility problems, because when 'const' is used right, it leaves
the decision to pass by reference or not to the compiler. So when this
changes, there shoudn't be any problem. 
But this is also the weak part of this solution: with this change the
developer will use 'const' to make the compiler pass the variable by
reference, which should be free for the compiler to decide.

(In other words: it will make the usage of 'const' parameters for
connecting with external (c) programs very difficult, because the
meaning of const will be difference than how c-compilers will handle it)

Second option is to change the 'iid' parameter of QueryInterface from
'const' to 'var'. This is not a really option, though, because then you
can not pass constant values to QueryInterface anymore. Which means that
you also can not pass an IInterface (and thus it's GUID) to it directly.

This leads to the third option: introduce a new parameter-type which
will always pass the variable by reference, and will be handled as being
constant by the compiler. We could name it 'in', for example.

First and third option are possible. I would choose for the third option
because this will also settle these kind of problems for the future.
(This idea is also mentioned on this list before by others)

Or are there any considerations/arguments that I missed?

Joost