mORMot Open Source

ComingNine

Member

Registered: 2010-07-29

Posts: 304

TDynArray.GuessKnownType behaves wrong for FPC Linux.

It seems that TDynArray.GuessKnownType behaves differently between Delphi Win32 and FPC Linux x86_64.
FPC is installed using the fpcupdeluxe tool and the latest 3.2 fixes branches.

As shown by the figure below, TDynArrayHashed.Init is called in SyNodeProto.TSMCustomProtoObject.Create.

As shown by the two figures below, TDynArrayHashed.Init goes through different routes between Delphi (win32) and FPC Linux x86_64 by design.

In the initialization of the associated hasher, i.e., TDynArrayHasher.Init, HashElement should be initialized to one of default functions. The HashElement under this circumstance is initialized to the function that handle djSynUnicode in Delphi, but nil in FPC Linux x86_64.

It seems that, under FPC Linux x86_64, the reason why the HashElement under this circumstance has been initialized to nil is related to GuessKnownType or related to RTTI. An nil HashElement will cause subsequent ReHash to fail...

Could you help to check and suggest how to fix ? Many thanks !

ComingNine

Member

Registered: 2010-07-29

Posts: 304

Re: TDynArray.GuessKnownType behaves wrong for FPC Linux.

For the time being, I have to put the following code to workaround this problem.
I also have to put in a property to write to Hasher.HashElement...

  FMethodsDA.Init(TypeInfo(TSMMethodDynArray), FMethods);
  // https://synopse.info/forum/viewtopic.php?id=7313
  {$IFNDEF MSWINDOWS}
  if @FMethodsDA.Hasher.DHashElement = nil then begin
    FMethodsDA.Hasher.DHashElement := DYNARRAY_HASHFIRSTFIELD[False, djSynUnicode];
  end;
  {$ENDIF}
  InitObject(aParent);

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 15,081

Website

Re: TDynArray.GuessKnownType behaves wrong for FPC Linux.

There is just not enough RTTI with FPC.

With mORMot 2, I tried to circumvent this AFAIR.

ComingNine

Member

Registered: 2010-07-29

Posts: 304

Re: TDynArray.GuessKnownType behaves wrong for FPC Linux.

There is just not enough RTTI with FPC.

With mORMot 2, I tried to circumvent this AFAIR.

Would it be possible for you to backport your workaround to mORMot 1 ?
Furthermore, could you suggest the proper way for me to register HashElement for TSMMethodDynArray ? My workaround just feels too hard-cast to be used...