From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows) Date: Tue, 14 Jul 2009 06:18:32 +0300 Message-ID: <83prc4q7ef.fsf@gnu.org> References: <7dbe73ed0907051401o26903ca3t9a67060f3a3417ad@mail.gmail.com> <83fxda1pef.fsf@gnu.org> <7dbe73ed0907060038w53699f77ie742996955ae8118@mail.gmail.com> <838wj11sz4.fsf@gnu.org> <83my7fz09s.fsf@gnu.org> <7dbe73ed0907081347q12dfd1a2lbbff915c49362f75@mail.gmail.com> <4A55D68D.8050407@gnu.org> <7dbe73ed0907090453s3e125b4ar142b90a268b105e2@mail.gmail.com> <7DAFC004A33C486A9E29A59689E7F02E@us.oracle.com> <4A5619F5.8010008@gnu.org> <8363e1zoak.fsf@gnu.org> <83hbxjrmue.fsf@gnu.org> <83ws6cqudb.fsf@gnu.org> <83tz1gqr33.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1247541527 12140 80.91.229.12 (14 Jul 2009 03:18:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jul 2009 03:18:47 +0000 (UTC) Cc: schwab@linux-m68k.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 14 05:18:40 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MQYXP-0000xq-QX for ged-emacs-devel@m.gmane.org; Tue, 14 Jul 2009 05:18:40 +0200 Original-Received: from localhost ([127.0.0.1]:41612 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQYXP-0007g9-66 for ged-emacs-devel@m.gmane.org; Mon, 13 Jul 2009 23:18:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQYXL-0007fq-Je for emacs-devel@gnu.org; Mon, 13 Jul 2009 23:18:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQYXK-0007fW-Hr for emacs-devel@gnu.org; Mon, 13 Jul 2009 23:18:35 -0400 Original-Received: from [199.232.76.173] (port=49808 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQYXK-0007fR-ER for emacs-devel@gnu.org; Mon, 13 Jul 2009 23:18:34 -0400 Original-Received: from mtaout4.012.net.il ([84.95.2.10]:56097 helo=mtaout3.012.net.il) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MQYXK-0004Xi-0g for emacs-devel@gnu.org; Mon, 13 Jul 2009 23:18:34 -0400 Original-Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KMR000004VFEV00@i_mtaout3.012.net.il> for emacs-devel@gnu.org; Tue, 14 Jul 2009 06:18:32 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.66.189]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KMR00GL556WEDD1@i_mtaout3.012.net.il>; Tue, 14 Jul 2009 06:18:32 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:112438 Archived-At: > From: Stefan Monnier > Cc: Andreas Schwab , emacs-devel@gnu.org > Date: Mon, 13 Jul 2009 20:54:14 -0400 > > > Aha. But it sounds like it's not just me who is confused. Here's > > just two examples: > > > From doc.c: > > > strp = SDATA (string); > > while (strp < SDATA (string) + SBYTES (string)) > > > (why not "while *strp"?) > > As said Andreas, this would stop at the first NUL, which may appear > within the string. But then a gazillion other places are buggy: we _do_ use SDATA(str) as a C string, and pass it to functions that will stop examining the string on the first null. A random example: d = opendir (SDATA (Fdirectory_file_name (encoded_dir))); What am I missing? > > From fileio.c: > > nm = (unsigned char *) alloca (SBYTES (filename) + 1); > > bcopy (SDATA (filename), nm, SBYTES (filename) + 1); > > (why +1? it potentially accesses memory beyond end of `filename's > > contents) > > The +1 is precisely used to make sure we copy the terminating NUL. That's not my reading of allocate_string_data. Are you sure? Anyway, if that's true, then again we have bugs in other places. Like this one: directory_nbytes = SBYTES (directory); if (directory_nbytes == 0 || !IS_ANY_SEP (SREF (directory, directory_nbytes - 1))) needsep = 1; [...] int nbytes = len + directory_nbytes + needsep; fullname = make_uninit_multibyte_string (nbytes, nbytes); bcopy (SDATA (directory), SDATA (fullname), directory_nbytes);