[fpc-devel] utf8 in 2.6.0

[Martin]

On 01/01/2013 14:24, Jonas Maebe wrote:
> On 01 Jan 2013, at 15:14, Martin wrote:
>
>> On my hardware it is normally all fine, but fails if I add the $codepage. I could spent a lot of work boiling that down to a sample. But given that I couldn't even find the docs what I really should expect,
> Without a {$codepage xxx} directive, string constants containing characters > #127 remain exactly as they appear in the source code.
>
> With a {$codepage xxx} directive, string constants containing characters > #127 are converted into unicodestrings during the parsing (according to the specified code page), and converted back into ansistrings (using the "ansi" code page of that particular program run) at run time if they are assigned to ansistring/shortstrings or passed to routines expecting such parameters.
>
> Note that the above is for 2.6.x (as the subject mentions).
>

ok, leaves me with my original problem.

On said ppc, using the original file (no codepage directive). file 
should be identical (svn checkout) (yet on 2nd thought I can't be sure, 
that it wasn't open in an editor and saved with utf8 bom...).

So on that ppc something goes wrong. From the feedback I had, it looks 
exactly as if the encoding of the constant was changed.  So what I was 
looking for was a way to 100% prevent that. Something that tells the 
compiler: Whatever encoding you find or expect or whatever encoding the 
output should be, do not touch strings. just take them byte by byte.
Does that exist?