From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24041 invoked by alias); 2 May 2011 08:08:47 -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: 29123 Received: (qmail 14335 invoked from network); 2 May 2011 08:08:44 -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 autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at vinc17.net does not designate permitted sender hosts) Date: Mon, 2 May 2011 10:08:39 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: completion on brace + 4 characters doesn't work Message-ID: <20110502080839.GG5625@prunille.vinc17.org> Mail-Followup-To: zsh-workers@zsh.org References: <20110428111148.GA3109@ypig.lip.ens-lyon.fr> <110428081240.ZM11395@torch.brasslantern.com> <20110428222754.GC5625@prunille.vinc17.org> <20110429003149.GA21935@prunille.vinc17.org> <20110429005909.GB21935@prunille.vinc17.org> <20110429013438.GC21935@prunille.vinc17.org> <110428205657.ZM12615@torch.brasslantern.com> <20110429084444.GE5625@prunille.vinc17.org> <110429072032.ZM13518@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <110429072032.ZM13518@torch.brasslantern.com> X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.21-6171-vl-r42848 (2011-03-30) On 2011-04-29 07:20:32 -0700, Bart Schaefer wrote: > On Apr 29, 10:44am, Vincent Lefevre wrote: > } > The code there apparently assumes a naive implementation of strcpy() > } > that goes left-to-right incrementing the source and destination > } > pointers in lock step. > } > } It also assumes that the length of the string is less than len > > Not really, because if the naive copy is done then the only thing > that matters is that len >= 0. Well, you can have a naive strcpy() implementation in the C library, but still the compiler is allowed to do any optimization, such as guessing the value of len (or some bounds) from the strcpy() call; this would not affect the behavior at strcpy(), but may affect the use of the len variable in some parts of the code. > } (because the source and the destination may not overlap). The > } compiler can use this fact to optimize the code. And as this is > } not true, the generated code may be incorrect. > > Yes, I was aware of all this, I just didn't think it was worth spelling > out (it's implicitly not "naive"). Keep in mind that this portion of > zle_tricky.c was written at least 10 years ago by a college student; > zsh was rarely if ever built with highly-optimized compilers/libc on > 64-bit platforms, at the time. > > Which is why I said: > > } > It would not surprise me to > } > find this assumption made elsewhere in the zsh sources. > > I don't suppose you could run through the entire "make check" test > suite under valgrind? Even that won't exercise everything but it'll > find the ones most likely to bite somebody. That would be a good idea. There's at least one: ==2490== Invalid read of size 1 ==2490== at 0x430AFE: execcmd (exec.c:3011) ==2490== by 0x42CAAC: execpline2 (exec.c:1640) ==2490== by 0x42BC2C: execpline (exec.c:1424) ==2490== by 0x42B2EA: execlist (exec.c:1207) ==2490== by 0x431723: execcmd (exec.c:3259) ==2490== by 0x42CAAC: execpline2 (exec.c:1640) ==2490== by 0x42BC2C: execpline (exec.c:1424) ==2490== by 0x42B2EA: execlist (exec.c:1207) ==2490== by 0x42AD64: execode (exec.c:1028) ==2490== by 0x4235A5: eval (builtin.c:4908) ==2490== by 0x423996: bin_eval (builtin.c:5017) ==2490== by 0x410936: execbuiltin (builtin.c:450) ==2490== Address 0xc22e213 is not stack'd, malloc'd or (recently) free'd It occurs in A04redirect.ztst. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)