From owner-cvs-lib  Fri Dec 13 04:45:58 1996
Return-Path: <owner-cvs-lib>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id EAA14386
          for cvs-lib-outgoing; Fri, 13 Dec 1996 04:45:58 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA14352;
          Fri, 13 Dec 1996 04:45:17 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id UAA08460;
          Fri, 13 Dec 1996 20:43:47 +0800 (WST)
Message-Id: <199612131243.UAA08460@spinner.DIALix.COM>
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: bde@zeta.org.au (Bruce Evans), cvs-all@freefall.freebsd.org,
        CVS-committers@freefall.freebsd.org, cvs-lib@freefall.freebsd.org,
        joerg@freefall.freebsd.org
Subject: Re: cvs commit: src/lib/libc/net ascii2addr.c 
In-reply-to: Your message of "Fri, 13 Dec 1996 10:22:47 +0100."
             <199612130922.KAA17521@uriah.heep.sax.de> 
Date: Fri, 13 Dec 1996 20:43:47 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-cvs-lib@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

J Wunsch wrote:
> As Bruce Evans wrote:
> 
> > This introduces an embarassing and rather obscure incarnation of an
> > uninitialized local variable use: now strbuf[15] is uninitialized.
> > strncpy(), unlike strncat(), does not null terminate the target string
> > if the source string together with its null terminator is longer than
> > the specified length.
> 
> Garrett did already point out this... fix will follow ASAP (unless
> somebody beats me at this :).

I'm not 100% sure of my facts here, so please don't shoot if I have
misunderstood...

Apparently, the ascii2addr()/addr2ascii() routines are specific to
the INRIA or NRL (defuct?) ipv6 code.  They don't seem to be part of
the bind-4.9.5 IPv6 code which is supposedly based on the "BSD API
drafts".  Since bind is the proverbial 500-pound gorilla that "sits
wherever it pleases" as such, we are pretty much required to maintain
at least the bind interfaces (inet_ntop/inet_pton etc).  See the
notes in src/contrib/bind/doc/misc/IPv6.  The bind versions are
"officially undocumented", but do support the current shape of the
IPv6 formatting.

Yes, I know that addr2ascii/ascii2addr are "generic" functions and not
IPv6 specific.  Both implemtnations appear to be very similar in
arg types and returns, but not quite identical.

Cheers,
-Peter