In message <200311242038.MAA12713@Pescadero.DSG.Stanford.EDU>, you write: 

-> 
-> In message <200311241913.hAOJDIvZ022577@fearless-vampire-killer.waterside.ne
-> t>Rafal Boni writes
-> 
-> [ usr.sbin/config newnv() leaves fields uninitialized ]
-> 
-> I'm amazed nobody else saw it -- unless the malloc support routines
-> changed in the meantime? But why not zero the whole nvlist structure,
-> as defensive programming:

Yeah, I'm rather suprised that it's biting *me* and nobody else i the
ass right now, where it used to all work before...  Not to mention,
annoyed too :-/

-> Index: util.c
-> ===================================================================
-> RCS file: /cvsroot/src/usr.sbin/config/util.c,v
-> retrieving revision 1.18
-> diff -u -r1.18 util.c
-> --- util.c	19 Sep 2003 06:19:56 -0000	1.18
-> +++ util.c	24 Nov 2003 20:33:29 -0000
-> @@ -190,6 +190,7 @@
->  		nv = emalloc(sizeof(*nv));
->  	else
->  		nvfreelist = nv->nv_next;
-> +	memset(nv, 0, sizeof(*nv));
->  	nv->nv_next = next;
->  	nv->nv_name = name;
->  	if (ptr == NULL)
-> 
-> or even move the memset() into config's emalloc()?  It shouldn't
-> be that big a factor in the run time.

That's probably better than my suggestion, as it is more defensive...

Tossing that memset in emalloc probably isn't a bad idea either (well,
given this bug, it's probably a better idea :-) , but then the various
free-to-local-freelist functions should also be audited (I haven't had
a chance to look if there are any beyond nvfree/nvfreel) and fixed.

--rafal

----
Rafal Boni                                                     rafal@pobox.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill