From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#8545: issues with recent doprnt-related changes Date: Thu, 28 Apr 2011 01:15:28 -0400 Message-ID: References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB65FF1.5010003@cs.ucla.edu> <83aafb8p4a.fsf@gnu.org> <4DB8ABEA.3080503@cs.ucla.edu> <4DB8DAF8.7070408@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1303969024 17945 80.91.229.12 (28 Apr 2011 05:37:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Apr 2011 05:37:04 +0000 (UTC) Cc: lekktu@gmail.com, 8545@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 28 07:37:00 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QFJuO-0002h6-1V for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Apr 2011 07:37:00 +0200 Original-Received: from localhost ([::1]:44740 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFJuN-0000lZ-Lk for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Apr 2011 01:36:59 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFJuG-0000cB-QA for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2011 01:36:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFJuF-0002gg-Jx for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2011 01:36:52 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFJuF-0002gb-IC for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2011 01:36:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QFJa6-0004Xq-8V; Thu, 28 Apr 2011 01:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Apr 2011 05:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130396773617436 (code B ref 8545); Thu, 28 Apr 2011 05:16:02 +0000 Original-Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:15:36 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFJZg-0004XA-1M for submit@debbugs.gnu.org; Thu, 28 Apr 2011 01:15:36 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFJZe-0004Wt-2a for 8545@debbugs.gnu.org; Thu, 28 Apr 2011 01:15:34 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QFJZY-0007Sr-8c; Thu, 28 Apr 2011 01:15:28 -0400 In-reply-to: <4DB8DAF8.7070408@cs.ucla.edu> (message from Paul Eggert on Wed, 27 Apr 2011 20:11:52 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 28 Apr 2011 01:16:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:46055 Archived-At: > Date: Wed, 27 Apr 2011 20:11:52 -0700 > From: Paul Eggert > CC: Eli Zaretskii , 8545@debbugs.gnu.org > > On 04/27/11 18:32, Juanma Barranquero wrote: > > > A cursory look suggests that fmt == format_end + 1 is possible > > Thanks, I had missed that possibility. (Evidently your cursory looks > are better than mine. :-) A possible patch is below. I strenuously object to that patch, see below. Please don't install it. > > would it be undefined behavior, > > as long as the pointer has not been dereferenced? > > Yes. A portable C program is not allowed to create a pointer that > doesn't point to an object, with the two exceptions of a null pointer > and a pointer to the address immediately after an object. On > some architectures, attempting to point to random addresses can cause > exceptions or other undefined behavior. As I explain in another message, we _can_ dereference this invalid pointer. Which is why that test was added in the first place. > - size_t n = *fmt - '0'; > - while (fmt < format_end > - && '0' <= fmt[1] && fmt[1] <= '9') > + size_t n = *fmt++ - '0'; > + while (fmt < format_end && '0' <= *fmt && *fmt <= '9') > { > if (n >= SIZE_MAX / 10 > || n * 10 > SIZE_MAX - (fmt[1] - '0')) > error ("Format width or precision too large"); > - n = n * 10 + fmt[1] - '0'; > - *string++ = *++fmt; > + n = n * 10 + *fmt - '0'; > + *string++ = *fmt++; > } > > if (size_bound < n) > size_bound = n; > } > else if (*fmt == '-' || *fmt == ' ' || *fmt == '.' || *fmt == '+') > - ; > + fmt++; > else if (*fmt == 'l') > { > long_flag = 1 + (fmt + 1 < format_end && fmt[1] == 'l'); > @@ -218,10 +217,7 @@ doprnt (char *buffer, register size_t bu > } > else > break; > - fmt++; > } > - if (fmt > format_end) > - fmt = format_end; I don't see how this is a better idea. Instead of a simple two-liner, which could be commented if its intent isn't clear enough, and which makes the code 100% verifiable to not dereference anything beyond format_end, how is it better to sprinkle weird post-increments in several places? This totally obfuscates the intent, does NOT allow to comment it in any reasonable way (because the increments are no longer in a single place, and serve more than one purpose), makes the code much harder to grasp and analyze, and makes it almost impossible to convince ourselves that it will never get past format_end without unduly complicated analysis. All that for getting rid of a simple and clearly correct line?? No, thanks!