
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">

<br>

<div>

<div>On 20 Nov 2013, at 16:12, Matt Miller <<a href="mailto:linuxwolf@outer-planes.net">linuxwolf@outer-planes.net</a>> wrote:</div>

<br class="Apple-interchange-newline">

<blockquote type="cite">

<div style="font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">

What I've consistently seen done right is dealing with null-termination for ASCII strings.  What I've consistently seen done wrong is the preparing of whatever input the API user has into the actual on-the-wire address.<br>

<br>

If not an ASCII null-terminated string, then we really ought to provide a helper function to do the most common preparation -- converting a string into binary address structure.<br>

</div>

</blockquote>

</div>

<br>

<div>With the caveat that it is actually possible to have both NULs (\0) and literal period characters (\. or \046) in a DNS label...</div>

<div><br>

</div>

<div>I'm not arguing that we need to support this, just pointing out that it should be noted as a limitation of any such function.  Alternatively, that function could accept "master file format" escaped (null terminated) strings.</div>

<div><br>

</div>

<div>Ray</div>

<div><br>

</div>

</body>

</html>