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: Fri, 29 Apr 2011 14:16:57 +0300 Message-ID: <83d3k571ee.fsf@gnu.org> References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB65FF1.5010003@cs.ucla.edu> <83aafb8p4a.fsf@gnu.org> <4DB8ABEA.3080503@cs.ucla.edu> <4DB9146D.2040702@cs.ucla.edu> <4DB9E5FF.9020506@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1304077022 10532 80.91.229.12 (29 Apr 2011 11:37:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 29 Apr 2011 11:37:02 +0000 (UTC) Cc: 8545@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 29 13:36:56 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 1QFm0F-0005WM-Gx for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Apr 2011 13:36:55 +0200 Original-Received: from localhost ([::1]:46279 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFm0E-0006OR-Vf for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Apr 2011 07:36:54 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFm0C-0006OF-1P for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2011 07:36:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFm0B-00045g-2N for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2011 07:36:51 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFm0A-00045c-VC for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2011 07:36:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QFlhy-0005qj-2f; Fri, 29 Apr 2011 07:18: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: Fri, 29 Apr 2011 11:18: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.130407585922455 (code B ref 8545); Fri, 29 Apr 2011 11:18:02 +0000 Original-Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 11:17:39 +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 1QFlha-0005q8-Pt for submit@debbugs.gnu.org; Fri, 29 Apr 2011 07:17:39 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFlhY-0005pv-O9 for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 07:17:38 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LKE00000V8K0G00@a-mtaout22.012.net.il> for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 14:16:57 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.124.129.123]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKE00MWSVC7CQ70@a-mtaout22.012.net.il>; Fri, 29 Apr 2011 14:16:57 +0300 (IDT) In-reply-to: <4DB9E5FF.9020506@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, 29 Apr 2011 07:18: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:46071 Archived-At: > Date: Thu, 28 Apr 2011 15:11:11 -0700 > From: Paul Eggert > CC: 8545-done@debbugs.gnu.org > > > If that's what you mean, it's easy to fix. Done. > > If I understand things correctly, that fix (in bzr 104036) handles the > case where the format itself has a non-ASCII character that is > truncated, but it doesn't handle the case where the format is > something like "file name = %s", and %s expands to a long file name > that is truncated. If so, surely that case still needs to be fixed. Ah, yes. Missed one more place where this truncation could happen. Should be fixed now (including an older bug with that code). > Yes, portable code is supposed to use va_copy. Code that traverses > through an argument list N times can call va_start once, va_copy N - 1 > times, and va_end N times (once on the original, once on each copy). > > va_copy is a C99-ism, but we can use it as-is in Emacs source code, > and use the relevant gnulib module for obsolete platforms that lack it. > Do the DOS and NT ports have va_copy? If not, it should be simple > to supply a substitute. The MS-DOS and MinGW builds use GCC, so they have va_copy by definition. MSVC doesn't, but we can provide a trivial definition which will work for x86. If we still support MSVC by the time Emacs can be built as a 64-bit executable on Windows, and if MSVC still doesn't have va_copy by that time, we can handle this better at that time. > Another possibility is to remove the 'if' test entirely, making it the > caller's responsibility to not specify outlandish widths in format > strings. I don't think this is a good idea. verror is in many cases the last line of defense, so it should IMO be rock-stable and try very hard to emit something useful even in the most improbable situations. For that reason, I also don't like the calls to `abort' you introduced. I understand the motivation (detection of invalid Emacs code), but why not make it call `error' instead, like we do here: switch (*fmt++) { default: error ("Invalid format operation %%%s%c", "ll" + 2 - long_flag, fmt[-1]); After all, using %ll when the long long data type isn't supported is not different from using %a or some other unsupported format letter, right? > OK, thanks. I read the code, and if I understand it correctly, since > 'point' is 1-origin, a buffer with MOST_POSITIVE_FIXNUM characters > will have values of 'point' ranging from 1 through > MOST_POSITIVE_FIXNUM + 1, but that "+ 1" would mean Fpoint wouldn't > work: so we should limit buffers to contain at most > MOST_POSITIVE_FIXNUM - 1 bytes. I guess so, yes. I would like to have other opinions, though, so I will start a new thread on emacs-devel about that. > Is it also the case that Emacs should limit strings to at most > MOST_POSITIVE_FIXNUM - 1 bytes? Only if we are thinking about copying a MOST_POSITIVE_FIXNUM-long string into a buffer. Otherwise, since string positions are zero-based, I think strings are safe with MOST_POSITIVE_FIXNUM. > Sorry, I couldn't tell this from the functions you mentioned; > there's a lot of code there, and this stuff isn't immediately > obvious. Yeah, tell me about that. I've been hacking that code extensively for the last year and a half, and I still don't always know who's who ;-)