pkg/39711: net/libfetch (as used by pkgtools/pkg_install) compilation error (+FIX)

[kre%munnari.OZ.AU@localhost]

>Number:         39711
>Category:       pkg
>Synopsis:       net/libfetch (as used by pkgtools/pkg_install) compilation 
>error (+FIX)
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 07 15:25:00 +0000 2008
>Originator:     Robert Elz
>Release:        NetBSD 4.0_STABLE  (pkgsrc current within last 8 hours)
>Organization:
        Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 4.0_STABLE NetBSD 4.0_STABLE 
(JADE-1.696-20080517) #9: Fri May 23 18:55:13 ICT 2008 
kre%jade.coe.psu.ac.th@localhost:/usr/obj/4/kernels/JADE i386
Architecture: i386
Machine: i386
>Description:
        The most recent change to net/libfetch introduced a potential
        use of an uninitialized variable (caught by gcc, and this one
        is real, not a bogus warning.)

>How-To-Repeat:
        I found it building pkgtools/pkg_install (which includes the
        sources of net/libfetch) which I do a lot, as I use pkg_comp
        with 3.0 (or occasionally 4.0) release sets installed, and rebuild
        the sandbox frequently.   That always (these days) means a new
        installion of the pkgtools (pkg_install) which because of its
        nature cannot be done by installation of the binary package that
        exists (it is what would do that) - so pkg_install gets compiled
        very frequently by me ...

        Tonight it failed...   Error was use of possibly uninitialised
        variable "next" in fetch_getln() from net/libfetch/files/common.c

        Rather than post the error messages, I'll just include a patch
        that makes the error go away - whether it is the correct fix
        I'll leave for someone ele to determine.   For me it is good
        enough, as while the potential use of the uninitialized variable
        was real (ie: is a real bug) the chances of it actually happening
        seem like they're pretty small (probably requires memory
        exhaustion or similar.)

>Fix:
        Applying the patch below makes pkg_install compile, install, and
        (as best I can tell from the few packages I have rebuilt since)
        work OK.

        Incidentally, since libfetch was changed, and libfetch is
        incorporated into pkg_install, shouldn't the version of
        pkg_install have been incrememted - the binary with this
        change (or the previous change to libfetch) is going to be
        different than the binary after it.   If this was a "regular"
        package it would mean a revbump, but since this one is
        maintained in source form entirely within pkgsrc, it shold
        just mean a new version ID (ie: date.)   And what happens
        with pkg_install when it changes twice in a day?

        This patch applies in pkgsrc/net/libfetch

--- files/common.c      2008-10-07 22:09:40.000000000 +0700
+++ files/common.c-PATCHED      2008-10-07 21:50:18.000000000 +0700
@@ -470,7 +470,7 @@
 int
 fetch_getln(conn_t *conn)
 {
-       char *tmp, *next;
+       char *tmp, *next = NULL;
        size_t tmpsize;
        ssize_t len;