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

[Joost van der Sluis]

On Sat, 2010-08-28 at 14:14 +0200, Marco van de Voort wrote:
> In our previous episode, Joost van der Sluis said:
> > 
> > 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.
> 
> The weak part of this kind of reasoning is that first the application
> crashes, and only a week the developer finds the reason.  If he is skilled
> enough.  Nearly all problems I had when porting big Delphi packages to FPC
> turned to be hidden assumptions like this, or string conversion assumptions.

Yes, you are completely right. That's why changing the queryinterface
definition from stdcall to cdecl isn't really a problem, because the
compiler will complain. This change will lead to hidden results.

> Of course, most of those are solved now, but this could produce similar
> problems on systems with multiple compilers that adhere to cdecl semantics.
> 
> > (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)
> 
> The problem is that currently we use the calling convention to decide all
> aspects of the ABI, not just calling convention.  This is specially a
> problem on systems where the ABI is not rigidly followed by everybody like
> on Windows.
> 
> The only solution is to fully parameterise the calling process (which
> registers to use, how and what const means const, how to use the stack, what
> to do with floating point (skip int regs for them or not) etc.  This might
> also allow to kill som assembler from the RTL, since you can do much more
> that defies the standard procedural regime in Pascal.
> 
> I've seen this in compilers before, but they didn't have the mass of
> parameters that FPC has. I don't know if it is doable. (and even if, it is
> probably a _major_ rewrite)

And only usable for professionals who know what they are doing. And
aren't you exaggerate it a bit? (schieten met een kanon op een mug) I
only need a forced pass-by-reference.

> > 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.
> 
> Getting back to the practical, if you really need to force byref, we need a
> way to force byref, period.  Delphi compatible or not.  A way to keep it
> delphi compat might be using a directive.  (e.g.  to specify the minimal
> size of byref passing)

Hmm... could be an idea. But then you can't manually decide which
paremeter should be passed by reference and which one not.
And isn't the suggested 'in' parameter type much cleaner in it's use?

> Because now cdecl is tuned to this application, but potentially hampering or
> breaking compatibility with others. And tomorrow a bugreport will be filed
> for another.

For example? I don't see where adding 'in' will lead to problems, except
that the code won't compile on Delphi anymore?

Joost