From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12410 invoked by alias); 29 Jan 2011 23:34:07 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28672 Received: (qmail 15894 invoked from network); 29 Jan 2011 23:34:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at ntlworld.com designates 81.103.221.47 as permitted sender) Date: Sat, 29 Jan 2011 23:33:58 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: coredump completing scp Message-ID: <20110129233358.0e33fee1@pws-pc.ntlworld.com> In-Reply-To: <110129151306.ZM7899@torch.brasslantern.com> References: <201101292216.p0TMGPm2003261@pws-pc.ntlworld.com> <110129151306.ZM7899@torch.brasslantern.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=NLZqzBF-AAAA:8 a=f_uFflS1VXNITsS0A5AA:9 a=DYFu-jfK1SL-sL_SWGoA:7 a=R_0pp3byLAJoMzlERuaUVbGoXN8A:4 a=CjuIK1q_8ugA:10 a=I6wTmPyJxzYA:10 a=_dQi-Dcv4p4A:10 a=Bo59AlFDroBO5YFU:21 a=b2LAcP_zom2L8_li:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 On Sat, 29 Jan 2011 15:13:06 -0800 Bart Schaefer wrote: > This sure seems like a bug in setpwent(), but I'll note that we're making > a call to setpwent() before ever calling getpwent() in the first place. > The doc says: > > The setpwent() function effectively rewinds the user database to allow > repeated searches. > > It may be that setpwent() assumes that getpwent() has allocated something > that it needs to free, something which never has been allocated because > getpwent() has never been called? And that only the zsh-mem free() has > a problem with this? Right, and since we always call endpwent() after all uses of getpwent(), we're guaranteed not to need setpwent() at all, aren't we? My reading is certainly that after endpwent() you're guaranteed to get the whole thing from scratch next time, which is all we need. --- ../zsh-git/zsh/Src/hashtable.c 2010-03-25 21:01:19.000000000 +0000 +++ Src/hashtable.c 2011-01-29 23:28:25.000000000 +0000 @@ -1339,8 +1339,6 @@ fillnameddirtable(UNUSED(HashTable ht)) #ifdef HAVE_GETPWENT struct passwd *pw; - setpwent(); - /* loop through the password file/database * * and add all entries returned. */ while ((pw = getpwent()) && !errflag) @@ -1379,8 +1377,6 @@ fillnameddirtable(UNUSED(HashTable ht)) #ifdef USE_GETPWENT struct passwd *pw; - setpwent(); - /* loop through the password file/database * * and add all entries returned. */ while ((pw = getpwent()) && !errflag) -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/