Hum, who are "they probably make assumptions"?
The fpc committers or the libraries of my applications?
Your application probably makes an assumption about the internal layout of the header that precedes ansistrings (tansirec in the system unit, rtl/inc/astrings.inc). This record type is not exported via the interface of the system unit, which means code outside the compiler/RTL cannot rely on its layout or contents (except via public helpers such as System.StringRefCount, as mentioned on the User Changes page).
Hello Jonas and thanks for answer.
After lot of long hours of trying to fix, I have to stop, I cannot fix it.
except via public helpers such as System.StringRefCount
Sadly StringRefCount works only for Tansistring and Tunicodestrings.
But could it be possible to think to add condition in the problematic commit.
After deep tests it appears that the problems occur with the patch done to
rtl/inc/astrings.inc and
/rtl/inc/ustrings ( patch for
compiler/aasmcnst.pas is OK. )
So the proposition is this, use a define to give the possibility to user to not use the patch:
This is the problematic patch in
rtl/inc/astrings.inc and
/rtl/inc/ustrings :
{$if not defined(VER3_0) and not defined(VER3_2)}
{$ifdef CPU64}
Ref : Longint;
{$else}
Ref : SizeInt;
{$endif}
{$else}
{$ifdef CPU64}
{ align fields }
Dummy : DWord;
{$endif CPU64}
Ref : SizeInt;
{$endif}
And replace by something like this (see
no64bitRref):
{$if (not defined(VER3_0)) and (not defined(VER3_2)) and (not defined(no64bitRref))} // here change
{$ifdef CPU64}
Ref : Longint;
{$else}
Ref : SizeInt;
{$endif}
{$else}
{$ifdef CPU64}
{ align fields }
Dummy : DWord;
{$endif CPU64}
Ref : SizeInt;
{$endif}
With this, if somebody does not want the new feature, just add that parameter at compil :
-dno64bitRrefAnd so everybody is happy, even the people that uses libraries that dont like the original commit.
Fre;D