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:02:13 -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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1303967224 10351 80.91.229.12 (28 Apr 2011 05:07:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Apr 2011 05:07:04 +0000 (UTC) Cc: 8545@debbugs.gnu.org, eggert@cs.ucla.edu To: Juanma Barranquero Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 28 07:06:57 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 1QFJRI-00072R-Q3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Apr 2011 07:06:56 +0200 Original-Received: from localhost ([::1]:50982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFJRI-0006mI-9r for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Apr 2011 01:06:56 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFJRD-0006lF-Hu for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2011 01:06:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFJRC-0006Eg-FY for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2011 01:06:51 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFJRC-0006Ec-9z for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2011 01:06:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QFJNV-0004Es-QM; Thu, 28 Apr 2011 01:03:01 -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:03:01 +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.130396694116239 (code B ref 8545); Thu, 28 Apr 2011 05:03:01 +0000 Original-Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:02:21 +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 1QFJMr-0004Dr-3s for submit@debbugs.gnu.org; Thu, 28 Apr 2011 01:02:21 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFJMp-0004De-Me for 8545@debbugs.gnu.org; Thu, 28 Apr 2011 01:02:20 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QFJMj-0006tz-IO; Thu, 28 Apr 2011 01:02:13 -0400 In-reply-to: (message from Juanma Barranquero on Thu, 28 Apr 2011 03:32:23 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 28 Apr 2011 01:03:01 -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:46052 Archived-At: > From: Juanma Barranquero > Date: Thu, 28 Apr 2011 03:32:23 +0200 > Cc: Eli Zaretskii , 8545@debbugs.gnu.org > > On Thu, Apr 28, 2011 at 01:51, Paul Eggert wrote: > > > If fmt is actually greater than format_end, it's pointing past the end > > of an object, so the C code is relying on undefined behavior and the > > check therefore isn't portable. > > I'm no expert on the C standard, but would it be undefined behavior, > as long as the pointer has not been dereferenced? A cursory look > suggests that fmt == format_end + 1 is possible, but fmt is not > dereferenced in that case. My (not-so cursory) look at the code suggests that we do dereference it, in this fragment: switch (*fmt++) { default: error ("Invalid format operation %%%s%c", long_flag ? "l" : "", fmt[-1]); If fmt > format_end, this will dereference the address beyond format_end. I thought showing the last character of the format string itself is a better idea. It is also exactly equivalent to what the code will do and display when *format_end == '\0'.