[fpc-pascal] FPC 3.3.x breaks the Firebird Project's Firebird.pas

Michael Van Canneyt michael at freepascal.org
Sat May 4 20:21:25 CEST 2024



On Sat, 4 May 2024, Tony Whyman via fpc-pascal wrote:

> Michael,
>
> I believe that the diplomatic answer to your response is that it is 
> "disappointing". This is a serious problem and needs to be discussed.

Thank you for being diplomatic.

>
> Interfaces between modules written in different programming languages or 
> even built with different compilers are never easy and depend on having 
> published and stable definitions for each data type and structure. This 
> is a common problem for anyone using Pascal given how so many code 
> libraries are written 'C' or C++. Change can imply breaking many user 
> programs and should not be done lightly and for purely internal reasons.

We guarantee backwards compatibility (as much as possible) on the language 
level and API level, but not on the internal structure of objects.

The only structure that is guaranteed to work with C or C++ is the record.

Hence my proposed solution using a record.

> Both object and class type data structures are published in the Free 
> Pascal Documentation

You may wish to re-read the documentation and specifically this:

https://www.freepascal.org/docs-html/current/ref/refsu23.html#x73-970006.3.1

'As of version 3.0 of the compiler, the compiler can re-order the fields in memory 
if this leads to better alignment and smaller instances. That means that in an instance, 
the fields do not necessarily appear in the same order as in the declaration.'

So your vTable also is in no way guaranteed to be correct, the above
explicitly says that your assumptions are invalid.

> In the case of monitor data, you have said that Delphi have implemented 
> this as a "hidden" field. I presume that you mean that this uses a 
> technique such as a negative offset to the object instance pointer.

No, actually behind all other fields.

I don't intend to do work on this, since nowhere was there any guarantee
that TObject has no fields. As I wrote, this assumption has no basis and
this is even documented. It works purely by chance, not through design.

I have given you a possible way to fix it, which is IMO the only correct and
future proof way to implement what you need.

Michael.


More information about the fpc-pascal mailing list