Supplementing my point below, I went back and checked my notes. The TObject layout post 3.2 (in my copy of trunk) is now

       TObject = class
       {$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
       strict private
          _MonitorData : Pointer;
       private
          function SetMonitorData(aData,aCheckOld : Pointer) : Pointer; inline;
          function GetMonitorData: Pointer; inline;
       {$ENDIF}
       protected
          function GetDisposed : Boolean; inline;
          Property Disposed : Boolean Read GetDisposed;
       public

with everything before "public" having been added. The big change is the addition of "_MonitorData". This bumps the offset of all later fields up by sizeof(pointer). If you have code that makes assumptions about the object layout - and this very much applies to code that tries to import an object from C++ then your previous assumptions are invalid.

The advice I got was that for external interfaces, only the "record" layout is immutable between versions. In the end, I had to remove all the Firebird interface code that relied on the assumption that the Pascal object layout was the same as the C++ and replaced it with extended records in order to mimimise the impact on code that used the API.

There's more information about the changes to my code on github https://github.com/MWASoftware/fbintf/tree/main/client/3.0/firebird

On 18/02/2026 08:39, Tony Whyman via fpc-pascal wrote:

    The object layout has changed post 3.2 with the addition of an
    extra field. This breaks any code that makes assumptions about
    this. I had a problem with the Firebird OO API due to this change
    (also interfacing to C++), and had to rewrite the Firebird/IBX
    interface moving away from OO to extended records.


-------- Original message --------
From: Adriaan van Os via fpc-pascal <[email protected]>
Date: 17/02/2026 17:05 (GMT+00:00)
To: FPC-Pascal users discussions <[email protected]>
Cc: Adriaan van Os <[email protected]>
Subject: [fpc-pascal] Corba ABI change ?

Has there been an ABI change in the trunk compiler (compared to fpc-3.2.4-rc1) for CORBA interfaces ? Maybe related to "Unicode"-strings ? I have some C++ interfacing code that works fine with
fpc-3.2.4-rc1 but crashes with the trunk compiler.

Any hints are appreciated.

Regards,

Adriaan van Os
_______________________________________________
fpc-pascal maillist  - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to