[fpc-devel] TRegistry and Unicode

[J. Gareth Moreton]

 If I may add my two pence...

 I'm all for speed and efficiency in library code, but conformance is more
important - if a correct input (even if somewhat extreme) results in a bad
output, then it's something that should be fixed.  If you try to feed the
unit malformed input and it predictably produces bad output, it's probably
permissible to leave it as is, since you're trying to break it.  To use
your example of UTF-8, it's perfectly reasonable to assume that Utf8Decode
is expecting valid UTF-8 data and attempt to decode it.  If you absolutely
have to determine if the string is valid UTF-8, then you should call
another function to determine if that is the case, and decide yourself how
to handle the situation if the string is invalid.

 The only time you should include sanity checks is in order to prevent
exceptions (e.g. reading beyond the end of the string even though a UTF-8
lead byte implies there's more data), but even then there are situations
where these could be allowed (e.g. if a subroutine takes a pointer as a
parameter, then it can be assumed that it isn't null).

 Gareth aka. Kit

 On Sun 10/03/19 22:40 , "Bart" bartjunk64 at gmail.com sent:
 On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt 
  wrote: 

 > I don't ever use the registry, so in that sense you are right it is
indeed 
 > not sexy enough to worry about it :-) 

 Neither do I use it... 

 Long time ago I wrote a patch for some other part of the RTL. 
 The old behaviour was plain wrong and resulted in wrong data. 
 When I wrote a patch that fixed the issue (string conversion into some 
 other data type), I was told was that the old implementation was 
 faster and therefor better. 

 I'm kind of feeling the same way now. 

 -- 
 Bart 
 _______________________________________________ 
 fpc-devel maillist - fpc-devel at lists.freepascal.org 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[1]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
------
[1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190310/216e3e21/attachment.html>