If you replied to this mail then you lost me.
 I don't understand what problem of UTF-8 for the RTL you want to point
 out. Can you explain again?
==============
Substringing etc manipulation only via normalizing to fixed-char type
which may be inefficient (especially because it performs for each
input argument & also for output - overhead multiplied by 3).
The ideal might be optimized (without pre/post-normalization) string
RTL with same set of procedures & functions & string related classes
for UTF-8, USC-2 & possibly UCS-4 or UTF-16 with working assignments
between them.
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to