[fpc-devel] String handling in trunk (was utf8 in 2.6.0)

[Ewald]

Once upon a time, on 01/07/2013 02:17 PM to be precise, Michael Schnell
said:
> So the ambiguity  with _filling_ a string with data in fact arises
> when _not_ using the #nn notation :-) . With #nn the effect (i.e. the
> resulting binary) is obvious.
Well, if there is literally the sequence $C7, $BE in your source code
(that is, open up a hex editor and actually see the values there, as one
byte each) that would also do the same, as the compiler will default to
one byte strings I think. The only issue with this is that you also need
to set your code editor to the encoding you want 'cause otherwise it
will screw up the display and possible binary value of the character.

So, yes I would say the #nn notation is probably the safest to use, also
handy if your character contains (or is) something that `cannot be
there`, like a newline: #10 (or #13#10 under windows)

Also, if you use a literal utf-16 char in the code (so no #nnnn, but the
actual character) I think the {$codepage utf16} directive might come in
handy, as otherwise the compiler will interpret this series of bytes as
sperate single bytes characters. This is however not an issue with the
#nnnn notation, as there is no ambiguity with this interpretation.

-- 
Ewald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20130107/fd9816a7/attachment.html>