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. 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) > 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) 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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
