<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>If I may add my two pence...<br>
<br>
<div>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.<br>
<br>
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).<br>
</div><div><br>
</div><div>Gareth aka. Kit<br>
</div><br>
 <br>
<br>
<span style="font-weight: bold;">On Sun 10/03/19 22:40 , "Bart" bartjunk64@gmail.com sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt
<br>

<<a href="javascript:top.opencompose('michael@freepascal.org','','','')">michael@freepascal.org</a>> wrote:
<br>


<br>

<span style="color: rgb(102, 102, 102);">> I don't ever use the registry, so in that sense you are right it is indeed
</span><br>

<span style="color: rgb(102, 102, 102);">> not sexy enough to worry about it :-)
</span><br>


<br>

Neither do I use it...
<br>


<br>

Long time ago I wrote a patch for some other part of the RTL.
<br>

The old behaviour was plain wrong and resulted in wrong data.
<br>

When I wrote a patch that fixed the issue (string conversion into some
<br>

other data type), I was told was that the old implementation was
<br>

faster and therefor better.
<br>


<br>

I'm kind of feeling the same way now.
<br>


<br>

-- 
<br>

Bart
<br>

_______________________________________________
<br>

fpc-devel maillist  -  <a href="javascript:top.opencompose('fpc-devel@lists.freepascal.org','','','')">fpc-devel@lists.freepascal.org</a>
<br>

<a target="_blank" href="parse.php?redirect=<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a>
<br>

<br>

<br>

</blockquote></HTML>