[fpc-devel] bug report 20473: Please add a directive to define string=utf8string

[michael.vancanneyt at wisa.be]

On Thu, 13 Oct 2011, Marco van de Voort wrote:

> In our previous episode, Sven Barth said:
>> I think he ment that if such a feature is introduced it would be a
>> natural conclusion to define "string = unicodestring" on Windows and
>> "string = utf8string" for Unix in the RTL and the FCL (and maybe "string
>> = ansistring" for DOS and OS/2). Thus those two libraries need to be
>> tested intensively that they can cope with that.
>
> No, worse even, both on both platforms. So win32-utf8 and win32-utf16, where
> the utf* designates the type of the default string type. And the same for
> unix.  Maybe win32-ansi too.
>
> Some of these are for the transition period and legacy only. I don't think
> "ansi" versions for non windows platforms are necessary in the long run, and
> maybe not even initially.  I haven't really made up my mind yet if the
> 1-byte target for unix should be utf8 specifically, or native encoding.
>
> This means 2 RTLs for all major platforms (say
> linux/freebsd/windows/darwin), and at least for a time an extra one (ansi,
> compat with old FPC and Delphi) on windows.  The others are up to the
> maintainer.
>
> The default stringtype is set on compiler startup, but can be modified
> inside procedures with $H like behaviour.
>
> So first you pick the general encoding first, depending on your plans and
> where your code originates from. The whole FPC distro will be compiled using
> that type as much as possible.
>
> If you need escape from it, you can workaround it in two ways:
>
> 1. (best choice) change the routines that need escape to proper typing. preferably update
>  the code to narrow the spot that is encoding dependent, and make the rest
>   "string"
> 2. Try a blanket {$H} to make the default stringtype what you want, and fix
>   problems (e.g. overrides of methods, passing to var params).

The blanket {$H} seems like the way to go for most packages.

If we insert {$H ANSISTRING}, then most packages should remain functional,
allowing us to tackle the packages one by one.

Codepage conversions should happen automatically, except for the case of 
Var params, but these need to be sorted out anyway.

But I would like to hear from Florian, Jonas or Paul whether they think this
is possible. If I remember correctly, Florian proposed something similar
some years ago.

Michael.