mORMot Open Source

alpinistbg

Member

Registered: 2014-11-12

Posts: 124

FPC 3.1.1 and SynCrossPlatformREST

Hello,

I've tried to use FPC in the most neutral way that comes to my mind - through CrossPlatform units, but then I found the following declaration in the SynCrossPlatformREST.pas:

type
  /// alias to share the same string type between client and server
  RawUTF8 = string;

from the other hand, in SynCommons.pas:

  {$ifdef HASCODEPAGE}
  RawUTF8 = type AnsiString(CP_UTF8); // Codepage for an UTF8 string
  {$else}
  RawUTF8 = type AnsiString;
  {$endif}

Although I know how to adjust the compiler directives to match both declarations, I am a bit confused which is the right way of using FPC for making a mORMot client. Regarding this forum, the FPC is not quite 'mORMot' ready to be a fully blown-up server/client.

Please advice!

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,207

Website

Re: FPC 3.1.1 and SynCrossPlatformREST

I understand this is confusing...

In short, SynCrossPlatform uses the "plain string" format of the compiler, i.e. AnsiString before Delphi 2009, UnicodeString for Delphi 2009+, and FPC standard string behavior.
Here, "RawUTF8" is just an alias, a trick "to share the same string type between client and server", but it does NOT use UTF-8 encoding for its storage.
So it is perfectly safe to use SynCrossPlatform's RawUTF8 as a plain string.
Note that there is no RawUTF8 = TYPE string - this is just a plain string, not a new type.

We tried to include the codepage feature available since latest FPC in SynCommons.pas.
But in its current state, it is not finished since we have issues with the current FPC implementation.
See http://synopse.info/forum/viewtopic.php … 498#p19498

alpinistbg

Member

Registered: 2014-11-12

Posts: 124

Re: FPC 3.1.1 and SynCrossPlatformREST

Dear ab,

Perhaps I'm adding a unnecessary fuzz here, but ... FPC wiki says: String is the same as AnsiString (with {H+}) and AnsiString is actually AnsiString(CP_ACP). In my case CP_ACP<>CP_UTF8 as probably in your case. One of my projects is already almost broken because of the new FPC way of dealing with strings. In that project I'm using mORMot and since it requires FPC 3.0+, my forms got weird messages with half readable letters and the other half cryptic. 

Anyway, Isn't it better for RawUTF8 to be AnsiString(CP_NONE) to bypass the internal conversions (and despite it's name)?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,207

Website

Re: FPC 3.1.1 and SynCrossPlatformREST

RawUTF8 is expected to be UTF-8 encoded.

And if you set AnsiString(CP_NONE) the internal conversions are made as if CP_NONE was CP_ACP: this is what breaks our regression tests expectations, AFAIR...