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 22:57:35 +0300 Message-ID: <83my77qbps.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> <83prc4q7ef.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1247601475 21234 80.91.229.12 (14 Jul 2009 19:57:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jul 2009 19:57:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 14 21:57:47 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 1MQo8J-0003AJ-Hz for ged-emacs-devel@m.gmane.org; Tue, 14 Jul 2009 21:57:47 +0200 Original-Received: from localhost ([127.0.0.1]:35382 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQo8I-0008Ly-O9 for ged-emacs-devel@m.gmane.org; Tue, 14 Jul 2009 15:57:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQo8E-0008LR-8G for emacs-devel@gnu.org; Tue, 14 Jul 2009 15:57:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQo8D-0008L4-KJ for emacs-devel@gnu.org; Tue, 14 Jul 2009 15:57:41 -0400 Original-Received: from [199.232.76.173] (port=50762 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQo8D-0008L0-GS for emacs-devel@gnu.org; Tue, 14 Jul 2009 15:57:41 -0400 Original-Received: from mtaout6.012.net.il ([84.95.2.16]:64396) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MQo8C-0000tb-Rs for emacs-devel@gnu.org; Tue, 14 Jul 2009 15:57:41 -0400 Original-Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KMS00C00FBD7N00@i-mtaout6.012.net.il> for emacs-devel@gnu.org; Tue, 14 Jul 2009 22:57:39 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.70.207.26]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KMS00IUAFFYLT40@i-mtaout6.012.net.il>; Tue, 14 Jul 2009 22:57:35 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) 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:112467 Archived-At: > From: Stefan Monnier > Cc: schwab@linux-m68k.org, emacs-devel@gnu.org > Date: Tue, 14 Jul 2009 14:18:53 -0400 > > > 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); > > make_uninit_multibyte_string calls allocate_string_data which does > > STRING_DATA (s)[nbytes] = '\0'; > > so the destination of the `bcopy' already has the terminating NUL. Perhaps most of the places where we use these paradigms are okay due to all these subtle corners that together make everything work. But IMHO it's inherently unsafe to use character arrays that are not true C strings as if they were C strings. For one, it violates the mental model each C programmer has about strings, and that can easily lead to misunderstanding, confusion, and bugs. For example (from dbusbind.c): char x[DBUS_MAXIMUM_SIGNATURE_LENGTH]; [...] strcpy (x, SDATA (CAR_SAFE (XD_NEXT_VALUE (elt)))); [...] sprintf (signature, "%c%s", dtype, x); or case DBUS_TYPE_SIGNATURE: { char *val = SDATA (Fstring_make_unibyte (object)); XD_DEBUG_MESSAGE ("%c %s", dtype, val); How can one convince herself that this code is safe without knowing too much about the Lisp strings whose data gets handled here as C strings? Can they have embedded nulls or cannot they? Same here (editfns.c): if (SBYTES (val) > message_length) { message_length = SBYTES (val); message_text = (char *)xrealloc (message_text, message_length); } bcopy (SDATA (val), message_text, SBYTES (val)); message2 (message_text, SBYTES (val), STRING_MULTIBYTE (val)); message_text[] is not a C string here, because it's not null-terminated (and doesn't have enough space to be terminated). Without looking at the implementation of message2, whose 1st arg is a `char *', how can one know that there's no bug here? Or here (search.c): raw_pattern_size = SCHARS (string); raw_pattern_size_byte = SCHARS (string); raw_pattern = (unsigned char *) alloca (raw_pattern_size + 1); copy_text (SDATA (string), raw_pattern, SBYTES (string), 1, 0); raw_pattern[] is not null-terminated, and we then use it, directly and indirectly, in many places. Without studying each use, there's no way you can determine that there cannot be a bug here. Etc., etc. -- I see other places where maybe it works, maybe it doesn't. One needs to study the code very carefully and look at many functions up and down the call stack, just to determine if a few lines don't constitute a bug.