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#8435: misuse of error ("...%d...", ...) on 64-bit hosts Date: Fri, 08 Apr 2011 11:58:44 +0300 Message-ID: <83vcypt8zf.fsf@gnu.org> References: <4D9CC60D.2090301@cs.ucla.edu> <4D9D68D8.6060200@cs.ucla.edu> <8339ltvrok.fsf@gnu.org> <4D9E21FB.70802@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1302253656 5908 80.91.229.12 (8 Apr 2011 09:07:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2011 09:07:36 +0000 (UTC) Cc: 8435@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 08 11:07:32 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q87f9-0004ME-J0 for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Apr 2011 11:07:31 +0200 Original-Received: from localhost ([127.0.0.1]:52133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q87f8-0001U4-Q1 for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Apr 2011 05:07:30 -0400 Original-Received: from [140.186.70.92] (port=38523 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q87ex-0001S8-3A for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2011 05:07:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q87ev-0007hK-Ti for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2011 05:07:18 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q87ev-0007hG-S4 for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2011 05:07:17 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Q87Zp-0001hM-Qb; Fri, 08 Apr 2011 05:02: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: Fri, 08 Apr 2011 09:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8435 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8435-submit@debbugs.gnu.org id=B8435.13022532926494 (code B ref 8435); Fri, 08 Apr 2011 09:02:01 +0000 Original-Received: (at 8435) by debbugs.gnu.org; 8 Apr 2011 09:01:32 +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 1Q87ZM-0001gh-6i for submit@debbugs.gnu.org; Fri, 08 Apr 2011 05:01:32 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q87Z5-0001gB-QE for 8435@debbugs.gnu.org; Fri, 08 Apr 2011 05:01:31 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LJB00700SZ9L000@a-mtaout22.012.net.il> for 8435@debbugs.gnu.org; Fri, 08 Apr 2011 12:00:46 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.239.68]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LJB006L5T18TMA0@a-mtaout22.012.net.il>; Fri, 08 Apr 2011 12:00:46 +0300 (IDT) In-reply-to: <4D9E21FB.70802@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 08 Apr 2011 05:02: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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:45688 Archived-At: > Date: Thu, 07 Apr 2011 13:43:39 -0700 > From: Paul Eggert > CC: 8435@debbugs.gnu.org > > > It also supported %c format for converting a multibyte character to > > its integer representation. > > This problem should be OK too. I manually inspected all the places > that used the %c format. All but one of them used %c only to convert > unibyte characters, so they're OK. The only exception was in > charset_iso_charset_parameter, and I modified that function to convert > the multibyte character before passing it as a string to 'error'. But we are losing a valuable feature this way, I think. From now on, any code that needs to use %c for displaying a character codepoint will need to convert it manually before calling the message functions. Taking a step back, this issue is about possible bugs when int and EMACS_INT data types are mixed up in the calls to functions that could either call doprnt or printf and its ilk. So I think it would be better to fix these problems as follows: . Introduce a printf format conversion specifier for converting an EMACS_INT data type. . Fix all the direct and indirect callers of doprnt to use this new specifier when the argument is an EMACS_INT. . Fix doprnt to avoid overflow when EMACS_INT is a 64-bit type, if it could overflow. (I don't see such a danger, but maybe I overlook something.) You already did the first two. So I think what my suggestion boils down to fixing doprnt (if needed) instead of introducing vsnprintf, and then all the additional problems caused by that introduction will be gone. So could you please tell what are the downsides of keeping doprnt instead of introducing vsnprintf? > Another issue has come up in further static analysis. The vsnprintf > API does not work for strings longer than INT_MAX bytes. For > vmessage's use of vsnprintf this is OK, since (for other reasons) a > frame title can't be that long. However, for verror this is an > arbitrary limitation on typical 64-bit hosts. I'll look into this, > and plan to propose a further patch to handle it. I don't think we have any reason to support strings longer than INT_MAX in these functions. They are used to display messages in the echo area/minibuffer, so they can hardly be close to INT_MAX anyway. We could simply document that and move on. For bullet-proof code, we could even check the length and truncate the string before passing it to verror or its subroutines. I also don't think we should remove message_nolog, even if it's currently unused. It's a useful function. If someone feels badly about having dead code, we could #ifdef it away, although I don't think it matters for such a short function.