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?
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
