On 11/29/2014 05:36 PM, Hans-Peter Diettrich wrote:
As Delphi doesn't allow for a dynamic encoding of CP_NONE, I don't
understand the purpose of the FPC description.
As you suggested in the other mail, the Delphi implementation of
RawByteString is decently flawed and this supposedly is introduced by
the compiler implementers not having understood what the language
architects had on their minds. (Documentation writers unsuccessfully
tried to make any sense of whet the implementation provides.)
Now in turn some FPC developer might have misunderstood the (Delphi)
handling of RawByteStrings, assuming that it were okay to omit a
conversion in an assignment of RawByteString to an AnsiString of a
different encoding.
IMHO a poor attempt to try to correct things in a way a little bit
compatible as well to the senseless description in Delphi docs as to the
flawed implementation. IMHO this can't result in anything useful, and
fpc with RawByteString should react with a compiler error or imitate the
flawed behavior as far as possible. If we really want a dynamic behavior
(which IMHO would be very welcome), we need a decent implementation of
same and this is very incompatible to RAWByteSring and hence needs an
additional type name (I suggest DynamicString) and encoding brand number
(I suggest CP_ANY = $FF00).
That's why I think that the incorrect handling of such RawByteString
assignments in FPC should be fixed,
That's why *I* think that the incorrect handling of such RawByteString
assignments in FPC should not be fixed, ;-)
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
