Hans-Peter Diettrich wrote 5 lines
IMO the Insert procedure should change the encoding of the
string-to-insert into the CP of the target string. Else the target
string can become unusable, containing an mix of characters from
different codepages. While a RawByteString can have any encoding, it
cannot have two encodings at the same time.
Is there a "decent" (regarding multi-element codes such as ubiquitous in utf-8) way at all to do "Insert" with arguments specifying *element* position ? (As discussed already multiple times, there is no use in re-defining Insert and other such functions in a way that they use other enumeration than element-position.)
The common agreement is that the user is discouraged to do any assumptions about element position specifications (other than "1" = start of the string and High(Integer) = as high as possible). Any such value needs to be taken from a calling "Pos()" or "Length()".
BTW, the documentation should be updated to RawByteString arguments.
Which kind of RawByteString ? AFAIK from your mails in the last few days, with Delphi RawByteString is kind of "dynamic", while with fpc, RawByteString is statically defined to be something similar to a byte array.
(BTW can in Delphi RawByteString take a 2 byte encoding such as utf-2, which is the default "String" in Delphi and if used that way so is pos(MyRawByteString) counting in Bytes or in Words ?)
OTOH, I understand that "insert", "Pos", "Copy", "Length", "Delete", "Concat" etc are built-in functions of with the arguments are "virtually" handled as if they had the non existing DynamicString Type and - if two arguments with different encoding brand are given - do *appropriate* auto-conversion. Otherwise no conversion of the input data to a fixed (i.e. the default "String") type is forced (which would be done if using a "normal" function with "String" as argument type).
Hence for RawByteString the behavior is undefined. As we already learned, the behavior of RawByteString usually is undefined, anyway,
-Michael
