From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Apr 2011 05:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 8545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8545@debbugs.gnu.org Cc: Eli Zaretskii X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.130371042216949 (code B ref -1); Mon, 25 Apr 2011 05:48:01 +0000 Received: (at submit) by debbugs.gnu.org; 25 Apr 2011 05:47:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEEdR-0004PJ-QA for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:47:02 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEEdP-0004Op-SU for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:47:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEEdJ-0000yv-RZ for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:46:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:42980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEEdJ-0000yq-Q4 for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:46:53 -0400 Received: from eggs.gnu.org ([140.186.70.92]:34848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEEdI-0003LV-Ua for bug-gnu-emacs@gnu.org; Mon, 25 Apr 2011 01:46:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEEdH-0000yZ-Oi for bug-gnu-emacs@gnu.org; Mon, 25 Apr 2011 01:46:52 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:57012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEEdH-0000xq-Fb; Mon, 25 Apr 2011 01:46:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id A617B39E80E0; Sun, 24 Apr 2011 22:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHaWohnIK7vt; Sun, 24 Apr 2011 22:46:42 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 19A6639E8082; Sun, 24 Apr 2011 22:46:42 -0700 (PDT) Message-ID: <4DB50AB9.6060100@cs.ucla.edu> Date: Sun, 24 Apr 2011 22:46:33 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.7 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.7 (----) This is a followup to Bug#8435. Eli invited me to review the recent doprnt-related changes, so here's a quick review: * doprnt returns size_t. But Stefan wrote that he prefers sizes to be signed values, and doprnt always returns a value that can fit in EMACS_INT. So shouldn't doprnt return EMACS_INT, as it did before? * doprnt supports only a small subset of the standard printf formats, but this subset is not documented. It's unclear what the subset is. Or it's a superset of the subset, with %S and %l? Anyway, this should be documented clearly in the lead comment. * I suggest that every feature in doprnt be a feature that is actually needed and used; this will simplify maintainance. * Format strings never include embedded null bytes, so there's no need for doprnt to support that. * If the format string is too long, the alloca inside doprnt will crash Emacs on some hosts. I suggest removing the alloca, instituting a fixed size limit on format specifiers, and documenting that limit. Since user code cannot ever supply one of these formats, that should be good enough. * The width features of doprnt (e.g., %25s) are never used. That part of the code is still buggy; please see some comments below. I suggest removing it entirely; this will simplify things. But if not: - doprnt mishandles format specifications such as %0.0.0d. It passes them off to printf, and this results in undefined behavior, near as I can tell. - doprnt uses atoi (&fmtcpy[1]), but surely this isn't right if there are flags such as '-'. - Quite possibly there are other problems in this area, but I didn't want to spend further time reviewing a never-used feature. * In this code, in verror: used = doprnt (buffer, size, m, m + mlen, ap); /* Note: the -1 below is because `doprnt' returns the number of bytes excluding the terminating null byte, and it always terminates with a null byte, even when producing a truncated message. */ if (used < size - 1) break; I don't see the reason for the "- 1". If you replace this with: used = doprnt (buffer, size, m, m + mlen, ap); if (used < size) break; the code should still work, because, when used < size, the buffer should be properly null-terminated. If it isn't then there's something wrong with doprnt, no? * In this code, in verror: else if (size < size_max - 1) size = size_max - 1; there's no need for the "- 1"s. Just use this: else if (size < size_max) size = size_max; * This code in verror: if (buffer == buf) buffer = (char *) xmalloc (size); else buffer = (char *) xrealloc (buffer, size); uses xrealloc, which is unnecessarily expensive, as it may copy the buffer's contents even though they are entirely garbage here. Use this instead, to avoid the useless copy: if (buffer != buf) xfree (buffer); buffer = (char *) xmalloc (size); From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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: Mon, 25 Apr 2011 09:01: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: To: Paul Eggert Cc: 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.1303722058984 (code B ref 8545); Mon, 25 Apr 2011 09:01:02 +0000 Received: (at 8545) by debbugs.gnu.org; 25 Apr 2011 09:00:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEHf7-0000Fp-ML for submit@debbugs.gnu.org; Mon, 25 Apr 2011 05:00:58 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEHf4-0000Fb-Rs for 8545@debbugs.gnu.org; Mon, 25 Apr 2011 05:00:56 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LK700100AC6JZ00@a-mtaout22.012.net.il> for 8545@debbugs.gnu.org; Mon, 25 Apr 2011 12:00:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.55.52]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LK7000E3AD4L3D0@a-mtaout22.012.net.il>; Mon, 25 Apr 2011 12:00:48 +0300 (IDT) Date: Mon, 25 Apr 2011 12:00:44 +0300 From: Eli Zaretskii In-reply-to: <4DB50AB9.6060100@cs.ucla.edu> X-012-Sender: halo1@inter.net.il Message-id: <83tydmaeo3.fsf@gnu.org> References: <4DB50AB9.6060100@cs.ucla.edu> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Sun, 24 Apr 2011 22:46:33 -0700 > From: Paul Eggert > CC: Eli Zaretskii > > This is a followup to Bug#8435. Eli invited me to review the recent > doprnt-related changes, so here's a quick review: Thanks for the review and the comments. > * doprnt returns size_t. But Stefan wrote that he prefers sizes to be > signed values, and doprnt always returns a value that can fit in > EMACS_INT. So shouldn't doprnt return EMACS_INT, as it did before? I made it return size_t because all the related variables in verror are size_t, and I didn't want to mix signed with unsigned. AFAIU, the preference to use signed is for those values that come from Lisp or go back to the Lisp level, which is not the case here. But I will let Stefan comment on this. Changing doprnt to return a signed value, and making the respective changes in verror, would be trivial, and I won't mind doing that, if that's the verdict. > * doprnt supports only a small subset of the standard printf formats, > but this subset is not documented. It's unclear what the subset is. > Or it's a superset of the subset, with %S and %l? Anyway, this > should be documented clearly in the lead comment. I added such a documentation. > * I suggest that every feature in doprnt be a feature that is actually > needed and used; this will simplify maintainance. I agree, but I didn't add any features, except the support for %ld, which is surely needed for error messages that show EMACS_INT values. All the rest was already there in the original code of doprnt. I see no reason to remove that code just because no error message currently uses some of those features. According to "bzr annotate", most of the related code in doprnt survived largely untouched since the 1990s, except some cleanup. This is no guarantee of being bug-free, of course, but it does have _some_ weight in my eyes. > * Format strings never include embedded null bytes, so there's > no need for doprnt to support that. Potentially, someone could call `error' with its first argument taken from a Lisp string, which could include null characters. But again, this feature was there to begin with, and I see no particular need to remove it. > * If the format string is too long, the alloca inside doprnt will > crash Emacs on some hosts. You are right. I modified doprnt to use SAFE_ALLOCA instead. > I suggest removing the alloca, > instituting a fixed size limit on format specifiers, and documenting > that limit. Since user code cannot ever supply one of these > formats, that should be good enough. GNU coding standards frown on arbitrary limits, so I didn't want to take that route, what with SAFE_ALLOCA readily available and easy to use. > * The width features of doprnt (e.g., %25s) are never used. Again, an old feature that I see no reasons to remove. And, since doprnt produces error messages meant to be displayed, I find that this feature actually makes sense. > - doprnt mishandles format specifications such as %0.0.0d. > It passes them off to printf, and this results in undefined > behavior, near as I can tell. Since both error and verror are now marked as ATTRIBUTE_FORMAT_PRINTF, the compiler will detect such invalid formats and flag them. If the warning is disregarded, the result of such a format is just a somewhat illegible message. In any case, vsnprintf would do the same, right? > - doprnt uses atoi (&fmtcpy[1]), but surely this isn't right if > there are flags such as '-'. Why not? In that case, atoi will produce a negative value for `width', which is already handled by the code. If I'm missing something, please point out the specific problems with that. > - Quite possibly there are other problems in this area, but I > didn't want to spend further time reviewing a never-used feature. I did read that code. It looked solid to me, but if you or someone else see specific problems, please point them out. > * In this code, in verror: > > used = doprnt (buffer, size, m, m + mlen, ap); > > /* Note: the -1 below is because `doprnt' returns the number of bytes > excluding the terminating null byte, and it always terminates with a > null byte, even when producing a truncated message. */ > if (used < size - 1) > break; > > I don't see the reason for the "- 1". If you replace this with: > > used = doprnt (buffer, size, m, m + mlen, ap); > > if (used < size) > break; > > the code should still work, because, when used < size, the buffer > should be properly null-terminated. If it isn't then there's something > wrong with doprnt, no? As the comment says, doprnt always null-terminates the result, even if the result is truncated, and it never returns a value larger than the buffer size it was given. (In that, it differs from vsnprintf, which can return larger values.) When doprnt does truncate the output string, it returns `size - 1'; if we compare against `size', we will happily bail out of the loop, and never try to enlarge the buffer. I saw no reason to enhance doprnt to continue processing the format string and the arguments once the buffer is exhausted. So I modified verror instead to DTRT. > * In this code, in verror: > > else if (size < size_max - 1) > size = size_max - 1; > > there's no need for the "- 1"s. Just use this: > > else if (size < size_max) > size = size_max; I made that change, thanks. The reason I originally limited to `size_max - 1' is that the games you play with the maximum size, viz.: size_t size_max = min (MOST_POSITIVE_FIXNUM, min (INT_MAX, SIZE_MAX - 1)) + 1; are neither clear nor commented. E.g., why the second `min'? could INT_MAX be ever larger than SIZE_MAX-1? if so, what does that mean in terms of relation between `int' and `size_t' on such a platform? I'm only familiar with a very small number of architectures, where all these tricks are unnecessary. When I see such code, it makes me dizzy and unsure of what I may be missing. So I opted for a safer way out (since error messages as long as SIZE_MAX are only theoretically possible), that would not risk overflowing signed values into the sign bit. Perhaps in the future you could comment such obscure code to make it understandable by mere mortals such as myself. > * This code in verror: > > if (buffer == buf) > buffer = (char *) xmalloc (size); > else > buffer = (char *) xrealloc (buffer, size); > > uses xrealloc, which is unnecessarily expensive, as it may copy the > buffer's contents even though they are entirely garbage here. Use > this instead, to avoid the useless copy: > > if (buffer != buf) > xfree (buffer); > buffer = (char *) xmalloc (size); You are right, I made that change. I believe this takes care of all the imminent problems you discovered in your review. Nevertheless, I will leave this bug report open for a while, to allow you and others to come up with more problems and suggestions for improvements. Thanks again for taking the time to review and comment. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Apr 2011 13:38: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org, Paul Eggert Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130373867627437 (code B ref 8545); Mon, 25 Apr 2011 13:38:02 +0000 Received: (at 8545) by debbugs.gnu.org; 25 Apr 2011 13:37:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QELz9-00078S-5T for submit@debbugs.gnu.org; Mon, 25 Apr 2011 09:37:55 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QELz7-00078H-1I for 8545@debbugs.gnu.org; Mon, 25 Apr 2011 09:37:53 -0400 Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:34645 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QELz1-0005es-Fs; Mon, 25 Apr 2011 09:37:47 -0400 Received: by ceviche.home (Postfix, from userid 20848) id EA0536618A; Mon, 25 Apr 2011 10:37:44 -0300 (ART) From: Stefan Monnier Message-ID: References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> Date: Mon, 25 Apr 2011 10:37:44 -0300 In-Reply-To: <83tydmaeo3.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 25 Apr 2011 12:00:44 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.0 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.0 (------) >> * doprnt returns size_t. But Stefan wrote that he prefers sizes to be >> signed values, and doprnt always returns a value that can fit in >> EMACS_INT. So shouldn't doprnt return EMACS_INT, as it did before? > I made it return size_t because all the related variables in verror > are size_t, and I didn't want to mix signed with unsigned. AFAIU, the > preference to use signed is for those values that come from Lisp or go > back to the Lisp level, which is not the case here. Mixing the two is what I find problematic, so if it's size_t all the way, that's OK. Stefan From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Apr 2011 06: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130379775517929 (code B ref 8545); Tue, 26 Apr 2011 06:03:01 +0000 Received: (at 8545) by debbugs.gnu.org; 26 Apr 2011 06:02:35 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEbM2-0004f8-BA for submit@debbugs.gnu.org; Tue, 26 Apr 2011 02:02:34 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEbM0-0004ex-6x for 8545@debbugs.gnu.org; Tue, 26 Apr 2011 02:02:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id B604E39E80F5; Mon, 25 Apr 2011 23:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Len4N+F1+bZG; Mon, 25 Apr 2011 23:02:26 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id E0ED639E8083; Mon, 25 Apr 2011 23:02:25 -0700 (PDT) Message-ID: <4DB65FF1.5010003@cs.ucla.edu> Date: Mon, 25 Apr 2011 23:02:25 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> In-Reply-To: <83tydmaeo3.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 04/25/11 02:00, Eli Zaretskii wrote: >> * Format strings never include embedded null bytes, so there's >> no need for doprnt to support that. > > Potentially, someone could call `error' with its first argument taken > from a Lisp string, which could include null characters. But again, > this feature was there to begin with, and I see no particular need to > remove it. The feature is buggy, because the code does not check fmt versus fmt_end every time it increases fmt; it checks only sometimes. Hence one can construct examples where doprnt will overrun the format, e.g., by having '%l' at the end of the format. If doprnt were written to expect a null-terminated string, which is what all its callers pass anyway, it would be simpler and easier to maintain and would not have this problem. "%l" is a strange case anyway, since one cannot reliably use "%l" as an alias for "%d". For example, the format "%dx" prints an integer followed by an 'x', but if you try to use "%lx" instead, it doesn't work. At least, we should remove "%l" as a format specifier, as it's a rightly-unused feature and it's just asking for trouble to try to support it. This should also fix the format-overrun bug mentioned earlier. >> * If the format string is too long, the alloca inside doprnt will >> crash Emacs on some hosts. > > You are right. I modified doprnt to use SAFE_ALLOCA instead. There's no need for alloca or SAFE_ALLOCA or xmalloc or any dynamic allocator. Instead, convert any width and precision values to integers, and use "*". For example, if the caller specifies this: "%012345.6789g", 3.14 pass this to sprintf: "%0*.*g", 12345, 6789, 3.14 That way, the format string itself has easily-bounded size and the code never needs to use alloca or xmalloc or whatever. > Since both error and verror are now marked as ATTRIBUTE_FORMAT_PRINTF, > the compiler will detect such invalid formats and flag them. Sure, but in that case why maintain code to implement the two formats (%S and %l) that are flagged invalid and are never used and should never be used? >> - doprnt uses atoi (&fmtcpy[1]), but surely this isn't right if >> there are flags such as '-'. > > Why not? In that case, atoi will produce a negative value for > `width', which is already handled by the code. If I'm missing > something, please point out the specific problems with that. I don't see how the negative value is handled correctly. %-10s means to print a string right-justified, but the code surely treats it as if it were %0s. And other flags are possible, e.g., atoi will parse "%0-3d" as if the width were zero, but the width is 3 (the "0" is a flag). A quick second scan found a minor bug in size parsing: the expression "n >= SIZE_MAX / 10" should be "n > SIZE_MAX / 10". > The reason I originally limited to `size_max - 1' is that the games > you play with the maximum size, viz.: > > size_t size_max = > min (MOST_POSITIVE_FIXNUM, min (INT_MAX, SIZE_MAX - 1)) + 1; > > are neither clear nor commented. E.g., why the second `min'? could > INT_MAX be ever larger than SIZE_MAX-1? if so, what does that mean in > terms of relation between `int' and `size_t' on such a platform? The C Standard allows INT_MAX to be larger than SIZE_MAX - 1, yes. I don't know of any current targets with that property, but it didn't hurt to be safe. The second 'min' was needed because vsnprintf can't create a string longer than INT_MAX bytes. Since doprnt doesn't have that silly limit, the above line should be changed to something like the following (this time with a comment :-): /* Limit the string to sizes that both Emacs and size_t can represent. */ size_t size_max = min (MOST_POSITIVE_FIXNUM + 1, SIZE_MAX); > You are right, I made that change. Thanks, can you make a similar change inside doprint? It also uses xrealloc where xfree+xmalloc would be better. One other thing, the documentation says that lower-case l is a flag, but it's a length modifer and not a flag. It must be specified after the precision (if given) and immediately before the conversion specifier character, and it cannot be intermixed with flags like 0 and - and +. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Apr 2011 20:26: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: To: Stefan Monnier Cc: Eli Zaretskii , 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13038495312787 (code B ref 8545); Tue, 26 Apr 2011 20:26:02 +0000 Received: (at 8545) by debbugs.gnu.org; 26 Apr 2011 20:25:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEop9-0000it-8r for submit@debbugs.gnu.org; Tue, 26 Apr 2011 16:25:31 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEop5-0000ie-Us for 8545@debbugs.gnu.org; Tue, 26 Apr 2011 16:25:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 66A4839E8100; Tue, 26 Apr 2011 13:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAvBaHlmTiqW; Tue, 26 Apr 2011 13:25:21 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id DF7B139E80FA; Tue, 26 Apr 2011 13:25:21 -0700 (PDT) Message-ID: <4DB72A31.8040203@cs.ucla.edu> Date: Tue, 26 Apr 2011 13:25:21 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.2 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) On 04/25/11 06:37, Stefan Monnier wrote: >> AFAIU, the >> > preference to use signed is for those values that come from Lisp or go >> > back to the Lisp level, which is not the case here. > Mixing the two is what I find problematic, so if it's size_t all the > way, that's OK. Sorry, but I don't see the general principle. Earlier, it was thought that emacs_write should return a signed value, because there's code like (emacs_write (...) != n) in fileio.c, where 'n' is signed, and signed-versus-unsigned comparison is problematic. I can certainly understand this point of view. With doprnt returning size_t, though, we still have this problem. In eval.c's verror we see this: size_t size_max = min (MOST_POSITIVE_FIXNUM, min (INT_MAX, SIZE_MAX - 1)) + 1; size_t used = ..., size = ...; ... while (1) { ... if (used < size - 1) break; if (size <= size_max / 2) size *= 2; else if (size < size_max) size = size_max; else break; /* and leave the message truncated */ ... } Here, the code is carefully comparing a signed value MOST_POSITIVE_FIXNUM to a possibly-different-width unsigned value SIZE_MAX - 1, storing the result into an unsigned variable, and using that unsigned variable. This comparison happens to be safe, but one has to stare at it a bit to make sure that the unsigned-versus-signed comparison isn't bogus. Why is this unsigned-versus-signed comparison OK, but the one with emacs_write problematic? I'm not saying this to be difficult: I'm just trying to understand the general principle here. I thought the point of preferring signed was so that we didn't have to worry about stuff like the above. Also I assumed the idea is that one should be able to compile GCC with -ftrapv and catch overflow errors. But if the above code is OK as-is, then clearly I'm misunderstanding the overall goal here. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Apr 2011 01: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: To: Paul Eggert Cc: Eli Zaretskii , 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130386690528236 (code B ref 8545); Wed, 27 Apr 2011 01:16:02 +0000 Received: (at 8545) by debbugs.gnu.org; 27 Apr 2011 01:15:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEtLM-0007LN-3b for submit@debbugs.gnu.org; Tue, 26 Apr 2011 21:15:04 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEtLJ-0007Kc-Tb for 8545@debbugs.gnu.org; Tue, 26 Apr 2011 21:15:02 -0400 Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:55253 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QEtLE-0007up-Gy; Tue, 26 Apr 2011 21:14:56 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 7348E660D8; Tue, 26 Apr 2011 22:14:54 -0300 (ART) From: Stefan Monnier Message-ID: References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB72A31.8040203@cs.ucla.edu> Date: Tue, 26 Apr 2011 22:14:54 -0300 In-Reply-To: <4DB72A31.8040203@cs.ucla.edu> (Paul Eggert's message of "Tue, 26 Apr 2011 13:25:21 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.0 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.0 (------) > Sorry, but I don't see the general principle. Earlier, it was > thought that emacs_write should return a signed value, because there's > code like (emacs_write (...) != n) in fileio.c, where 'n' is > signed, and signed-versus-unsigned comparison is problematic. > I can certainly understand this point of view. That's the point of view, yes. > With doprnt returning size_t, though, we still have this problem. I haven't looked at the code. I only commented based on Eli's description, who said that all the relevant code used size_t. Personally, I'd use `int' for such things, since any message larger than 2GB should be a sign that something went very wrong long before. Stefan From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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: Wed, 27 Apr 2011 20:12: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: To: Paul Eggert Cc: 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13039350751774 (code B ref 8545); Wed, 27 Apr 2011 20:12:02 +0000 Received: (at 8545) by debbugs.gnu.org; 27 Apr 2011 20:11:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFB4s-0000SZ-SL for submit@debbugs.gnu.org; Wed, 27 Apr 2011 16:11:15 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFB4p-0000SK-7f for 8545@debbugs.gnu.org; Wed, 27 Apr 2011 16:11:13 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LKB00400SX0EG00@a-mtaout20.012.net.il> for 8545@debbugs.gnu.org; Wed, 27 Apr 2011 22:34:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.32.146]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKB002TGT1QV4J0@a-mtaout20.012.net.il>; Wed, 27 Apr 2011 22:34:41 +0300 (IDT) Date: Wed, 27 Apr 2011 22:34:45 +0300 From: Eli Zaretskii In-reply-to: <4DB65FF1.5010003@cs.ucla.edu> X-012-Sender: halo1@inter.net.il Message-id: <83aafb8p4a.fsf@gnu.org> References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB65FF1.5010003@cs.ucla.edu> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Mon, 25 Apr 2011 23:02:25 -0700 > From: Paul Eggert > CC: 8545@debbugs.gnu.org > > On 04/25/11 02:00, Eli Zaretskii wrote: > > >> * Format strings never include embedded null bytes, so there's > >> no need for doprnt to support that. > > > > Potentially, someone could call `error' with its first argument taken > > from a Lisp string, which could include null characters. But again, > > this feature was there to begin with, and I see no particular need to > > remove it. > > The feature is buggy, because the code does not check > fmt versus fmt_end every time it increases fmt; it checks > only sometimes. I added more checks, thanks for pointing this out. > "%l" is a strange case anyway, since one cannot reliably use > "%l" as an alias for "%d". For example, the format "%dx" prints > an integer followed by an 'x', but if you try to use "%lx" instead, > it doesn't work. At least, we should remove "%l" as a format > specifier, as it's a rightly-unused feature and it's just asking > for trouble to try to support it. You convinced me, so I removed %l. > >> * If the format string is too long, the alloca inside doprnt will > >> crash Emacs on some hosts. > > > > You are right. I modified doprnt to use SAFE_ALLOCA instead. > > There's no need for alloca or SAFE_ALLOCA or xmalloc or any > dynamic allocator. Instead, convert any width and precision > values to integers, and use "*". For example, if the caller > specifies this: > > "%012345.6789g", 3.14 > > pass this to sprintf: > > "%0*.*g", 12345, 6789, 3.14 I see no reason for such complexity, just to avoid SAFE_ALLOCA. But feel free to make this change, if you think it's important enough. > >> - doprnt uses atoi (&fmtcpy[1]), but surely this isn't right if > >> there are flags such as '-'. > > > > Why not? In that case, atoi will produce a negative value for > > `width', which is already handled by the code. If I'm missing > > something, please point out the specific problems with that. > > I don't see how the negative value is handled correctly. > %-10s means to print a string right-justified, but the code > surely treats it as if it were %0s. ??? %-10s means to print a string LEFT-justified, and the code handles that in this loop (which runs after the string was copied to its destination): if (minlen < 0) { while (minlen < - width && bufsize > 0) { *bufptr++ = ' '; bufsize--; minlen++; } minlen = 0; } I actually tried using %-30s, and it did work correctly (as did %30s). > And other flags > are possible, e.g., atoi will parse "%0-3d" as if the > width were zero, but the width is 3 (the "0" is a flag). The code doesn't call atoi for numeric arguments. It delegates that case to sprintf, which will handle the likes of %0-3d correctly. And for %s and %c the "0" flag is not supported anyway (as stated in the comments) and GCC flags that with a warning. So I see no problem here. > A quick second scan found a minor bug in size parsing: the > expression "n >= SIZE_MAX / 10" should be "n > SIZE_MAX / 10". When they get to messages as long as SIZE_MAX, let them sue me for taking away one byte. verror will reject SIZE_MAX-long messages anyway, so I see no reason to squeeze one more byte here just to throw it away there. > /* Limit the string to sizes that both Emacs and size_t can represent. */ > size_t size_max = min (MOST_POSITIVE_FIXNUM + 1, SIZE_MAX); "MOST_POSITIVE_FIXNUM + 1" is too much, since MOST_POSITIVE_FIXNUM should be able to cover the terminating null character in Emacs. So I used this: size_t size_max = min (MOST_POSITIVE_FIXNUM, SIZE_MAX); > Thanks, can you make a similar change inside doprint? It > also uses xrealloc where xfree+xmalloc would be better. Done. > One other thing, the documentation says that lower-case l > is a flag, but it's a length modifer and not a flag. I fixed the doc on that account. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Apr 2011 23:52: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130394827621140 (code B ref 8545); Wed, 27 Apr 2011 23:52:01 +0000 Received: (at 8545) by debbugs.gnu.org; 27 Apr 2011 23:51:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFEVo-0005Uu-7s for submit@debbugs.gnu.org; Wed, 27 Apr 2011 19:51:16 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFEVl-0005Uh-JW for 8545@debbugs.gnu.org; Wed, 27 Apr 2011 19:51:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C2A1439E80FF; Wed, 27 Apr 2011 16:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEMXG-NOpE0E; Wed, 27 Apr 2011 16:51:07 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 1C74339E80DB; Wed, 27 Apr 2011 16:51:07 -0700 (PDT) Message-ID: <4DB8ABEA.3080503@cs.ucla.edu> Date: Wed, 27 Apr 2011 16:51:06 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB65FF1.5010003@cs.ucla.edu> <83aafb8p4a.fsf@gnu.org> In-Reply-To: <83aafb8p4a.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.2 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) On 04/27/11 12:34, Eli Zaretskii wrote: > I added more checks, thanks for pointing this out. Thanks, but I don't see the need for this newly-added check: if (fmt > format_end) fmt = format_end; 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. But how can fmt ever be greater than format_end here? I suggest removing the check. > ??? %-10s means to print a string LEFT-justified, and the code handles > that in this loop... > for %s and %c the "0" flag is not supported anyway (as stated in the > comments) and GCC flags that with a warning. Good points both; thanks. >> A quick second scan found a minor bug in size parsing: the >> expression "n >= SIZE_MAX / 10" should be "n > SIZE_MAX / 10". > > When they get to messages as long as SIZE_MAX, let them sue me for > taking away one byte. It's not a question of saving space at run-time. It's a question of helping the reader. The reader is left wondering: why is that ">=" there? And why is there another test "n * 10 > SIZE_MAX - (fmt[1] - '0')" that always returns 0, no matter what? Code like that will puzzle future maintainers, who may well mess it up later because they don't know what's going on. Also, most printf implementations will mess up if given a width or precision greater than INT_MAX, so I suggest not allowing widths or precisions greater than that. In summary, I suggest replacing this: if (n >= SIZE_MAX / 10 || n * 10 > SIZE_MAX - (fmt[1] - '0')) error ("Format width or precision too large"); with this: /* Avoid int overflow, because many sprintfs seriously mess up with widths or precisions greater than INT_MAX. Avoid size_t overflow, since our counters use size_t. This test is slightly conservative, for speed and simplicity. */ if (n >= min (INT_MAX, SIZE_MAX) / 10) error ("Format width or precision too large"); > "MOST_POSITIVE_FIXNUM + 1" is too much, since MOST_POSITIVE_FIXNUM > should be able to cover the terminating null character in Emacs. Why? Emacs size fields count the bytes in the string, and does not count the terminating null byte (which is not part of the string). In briefly reviewing the new version, I found that doprnt doesn't support the "ll" modifier for "long long", and thus wouldn't port to platforms that use long long for EMACS_INT. This is easy to fix, so I installed a fix for that. I also found three more problems: * doprnt invokes strlen to find the length of the format. The vsnprintf code didn't need to do that: it traversed the format once. Surely it shouldn't be hard to change doprnt so that it traverses the format once rather than twice. * Sometimes verror will incorrectly truncate a string, even when there is plenty of memory. verror might call doprnt (buffer, SIZE, m, m + mlen, ap), and doprnt might discover that a multibyte character is chopped in half at the end of the output buffer, and might return (say) SIZE - 2. verror will incorrectly conclude that the output was just fine, but it wasn't complete. * verror might invoke doprnt two or more times, which means that doprnt will traverse ap twice. This does not work in general; the C standard is quite clear that the behavior is undefined in this case. One way to fix this would be to modify doprnt so that it always walks through the format completely, and generates all the output that it is going to generate, and that it reallocates the output buffer as needed as it goes. This would require an API change. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Juanma Barranquero 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 01:34: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: To: Paul Eggert Cc: Eli Zaretskii , 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130395439130013 (code B ref 8545); Thu, 28 Apr 2011 01:34:02 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 01:33:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFG6Q-0007o2-Lb for submit@debbugs.gnu.org; Wed, 27 Apr 2011 21:33:10 -0400 Received: from mail-yi0-f44.google.com ([209.85.218.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFG6O-0007ns-MD for 8545@debbugs.gnu.org; Wed, 27 Apr 2011 21:33:09 -0400 Received: by yic13 with SMTP id 13so861618yic.3 for <8545@debbugs.gnu.org>; Wed, 27 Apr 2011 18:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=0bOxtlzCrViR35wZM7+RZqsqQt3zFv447C7TV27KPEE=; b=KwJ4ShXUyzw1qJvn1G3ktvhSoI9CT6q0zJUFM+QgeTepYHHCXfv1+vJpPtv1r6GGNg g+uDcgFGurC43CjUvcS6pG79l8QWobpV1/PAWhLQTmEqjPhcjhSXTHcSMFbKt5zcN3C8 5ZGQJHbTwTu7nQQqiPOweKiPF/VtAcdoViKJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=fBkyFWYwVlR1Mlbty++2XB4EX7u8hzRHCy1BU1oyHSih3FZTOX6C9R/cPeKIWEcbni Xb0WMOywvzI/7ddf2x2hBr5YofYotWHmgpsi/C8mhmfxQLsBE+bAND+F1kk8SYyuASam wHfBK7WYWDzFSzHfnvH310PtAwLifElmOr65c= Received: by 10.236.72.226 with SMTP id t62mr3474363yhd.495.1303954383079; Wed, 27 Apr 2011 18:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.182.5 with HTTP; Wed, 27 Apr 2011 18:32:23 -0700 (PDT) In-Reply-To: <4DB8ABEA.3080503@cs.ucla.edu> References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB65FF1.5010003@cs.ucla.edu> <83aafb8p4a.fsf@gnu.org> <4DB8ABEA.3080503@cs.ucla.edu> From: Juanma Barranquero Date: Thu, 28 Apr 2011 03:32:23 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.3 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) 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 =3D=3D format_end + 1 is possible, but fmt is not dereferenced in that case. =C2=A0 =C2=A0 Juanma From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert 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 03:13: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: To: Juanma Barranquero Cc: Eli Zaretskii , 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13039603226283 (code B ref 8545); Thu, 28 Apr 2011 03:13:02 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 03:12:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFHe6-0001dI-5n for submit@debbugs.gnu.org; Wed, 27 Apr 2011 23:12:02 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFHe3-0001ct-P9 for 8545@debbugs.gnu.org; Wed, 27 Apr 2011 23:12:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 2242F39E80F8; Wed, 27 Apr 2011 20:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4EEZpPFTaOd; Wed, 27 Apr 2011 20:11:53 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 80DAC39E80DB; Wed, 27 Apr 2011 20:11:53 -0700 (PDT) Message-ID: <4DB8DAF8.7070408@cs.ucla.edu> Date: Wed, 27 Apr 2011 20:11:52 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB65FF1.5010003@cs.ucla.edu> <83aafb8p4a.fsf@gnu.org> <4DB8ABEA.3080503@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) 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. > 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. === modified file 'src/doprnt.c' --- src/doprnt.c 2011-04-27 23:04:20 +0000 +++ src/doprnt.c 2011-04-28 03:00:59 +0000 @@ -194,22 +194,21 @@ doprnt (char *buffer, register size_t bu This might be a field width or a precision; e.g. %1.1000f and %1000.1f both might need 1000+ bytes. Parse the width or precision, checking for overflow. */ - 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; *string = 0; /* Make the size bound large enough to handle floating point formats From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Juanma Barranquero 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 03:44: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: To: Paul Eggert Cc: Eli Zaretskii , 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13039622039020 (code B ref 8545); Thu, 28 Apr 2011 03:44:01 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 03:43:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFI8R-0002LR-EM for submit@debbugs.gnu.org; Wed, 27 Apr 2011 23:43:23 -0400 Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFI8L-0002L9-Lz for 8545@debbugs.gnu.org; Wed, 27 Apr 2011 23:43:22 -0400 Received: by gyf3 with SMTP id 3so884337gyf.3 for <8545@debbugs.gnu.org>; Wed, 27 Apr 2011 20:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ImKPrf6upaMe9dEx9GrWQvsix8YCCfBabOGoGKtGVUA=; b=IkNY35uL682xDtyl7UkYKHlZ8jfEyVQisnuuP6f46mzlxq3cQ4O9jOHo1NFsc0iipo WyRkFvdbWt2pLQowTK4BBsUJRrnjmwXEXh1v1Re4Tesyq5WXeYsTJRpD608vSJ0G6IUj PtuEb7dA3FlG7lZhEhIbtOe0uWuW3+NVgxSnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=qTH1fFg82khgA2dpvcQ60wn3FMntayPs+9yQ2C5uxTRaN97iIbP6eB5FqTKgoTS0R+ TcrDSKvA4Rd+2JWdQxo8TyUW7WFa2YuRUPJC76AqQDIQNe81t9h/b2d6Ysw3HARne6Cs 6rUQ8+Vbx2SBWS8xNkcwS15EIVtmn6JO3khDM= Received: by 10.236.176.6 with SMTP id a6mr3490692yhm.428.1303962192090; Wed, 27 Apr 2011 20:43:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.182.5 with HTTP; Wed, 27 Apr 2011 20:42:32 -0700 (PDT) In-Reply-To: <4DB8DAF8.7070408@cs.ucla.edu> 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> From: Juanma Barranquero Date: Thu, 28 Apr 2011 05:42:32 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.3 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) On Thu, Apr 28, 2011 at 05:11, Paul Eggert wrote: >> would it be undefined behavior, >> as long as the pointer has not been dereferenced? > > Yes. =C2=A0A 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. That's weird, because it would mean that every pointer variable must be initialized (either explicitly to some value, or implicitly to the null pointer), or else the program will have undefined behavior. Anyway, in this case fmt =3D=3D format_end + 1 would point to the address immediately after an object, wouldn't it? > On > some architectures, attempting to point to random addresses can cause > exceptions or other undefined behavior. On dereferencing, sure. But just on assignment to the pointer variable? =C2=A0 =C2=A0 Juanma From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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: To: Juanma Barranquero Cc: 8545@debbugs.gnu.org, eggert@cs.ucla.edu Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130396694116239 (code B ref 8545); Thu, 28 Apr 2011 05:03:01 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:02:21 +0000 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 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 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 Date: Thu, 28 Apr 2011 01:02:13 -0400 Message-Id: From: Eli Zaretskii In-reply-to: (message from Juanma Barranquero on Thu, 28 Apr 2011 03:32:23 +0200) References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB65FF1.5010003@cs.ucla.edu> <83aafb8p4a.fsf@gnu.org> <4DB8ABEA.3080503@cs.ucla.edu> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > 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'. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert 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:07: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: To: Juanma Barranquero Cc: Eli Zaretskii , 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130396719316624 (code B ref 8545); Thu, 28 Apr 2011 05:07:02 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:06:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFJQv-0004K5-JH for submit@debbugs.gnu.org; Thu, 28 Apr 2011 01:06:33 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFJQt-0004Jq-8Q for 8545@debbugs.gnu.org; Thu, 28 Apr 2011 01:06:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id A3F8539E80F8; Wed, 27 Apr 2011 22:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC-6jG2cZgmk; Wed, 27 Apr 2011 22:06:24 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 612D039E80DB; Wed, 27 Apr 2011 22:06:24 -0700 (PDT) Message-ID: <4DB8F5CF.8090505@cs.ucla.edu> Date: Wed, 27 Apr 2011 22:06:23 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 04/27/11 20:42, Juanma Barranquero wrote: > in this case fmt == format_end + 1 would point to the address > immediately after an object, wouldn't it? No, format_end is already pointing after the object; the object's size is format_end - format. So format_end + 1 might not be a valid pointer. > That's weird, because it would mean that every pointer variable must > be initialized (either explicitly to some value, or implicitly to the > null pointer), or else the program will have undefined behavior. No, undefined behavior occurs only when an (invalid) pointer value is created (e.g., by casting from integer, or by adding to another pointer variable), or copied. It doesn't occur merely because storage is allocated for a pointer variable. In this respect, it's like creating an (invalid) integer value. If you assign i = INT_MAX + 1, the resulting behavior is undefined. It's the same if you assign p = &x + 2. That doesn't mean "char *p;" has undefined behavior, any more than "int i;" does. > On dereferencing, sure. But just on assignment to the pointer variable? Yes. To take an extreme example, some architectures can compute a pointer only by using a special pointer register, and the register's contents are always checked for validity, even if you don't dereference the pointer. I don't know whether Emacs has been ported to these machines, but there are also problems with pointers wrapping around even on more-conventional architectures. This issue is covered by one of the questions in the C FAQ; see . From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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: To: Paul Eggert Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130396773617436 (code B ref 8545); Thu, 28 Apr 2011 05:16:02 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:15:36 +0000 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 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 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 Date: Thu, 28 Apr 2011 01:15:28 -0400 Message-Id: From: Eli Zaretskii In-reply-to: <4DB8DAF8.7070408@cs.ucla.edu> (message from Paul Eggert on Wed, 27 Apr 2011 20:11:52 -0700) 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> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > 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! From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert 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:30:03 +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: To: Eli Zaretskii Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130396857618633 (code B ref 8545); Thu, 28 Apr 2011 05:30:03 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:29:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFJnD-0004qU-CE for submit@debbugs.gnu.org; Thu, 28 Apr 2011 01:29:35 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFJnA-0004qJ-Fe for 8545@debbugs.gnu.org; Thu, 28 Apr 2011 01:29:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C8EA039E80F8; Wed, 27 Apr 2011 22:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7VjjE42tDw9; Wed, 27 Apr 2011 22:29:26 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 381AA39E80DB; Wed, 27 Apr 2011 22:29:26 -0700 (PDT) Message-ID: <4DB8FB35.5090205@cs.ucla.edu> Date: Wed, 27 Apr 2011 22:29:25 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 04/27/11 22:15, Eli Zaretskii wrote: > As I explain in another message, we _can_ dereference this invalid > pointer. Sorry, I'm not quite following, since I'm not sure what the "another message" refers to. Hmm, perhaps you're talking about this pattern in the code? while (fmt < format_end) { ... fmt++ ... } switch (*fmt++) Here, the code is dereferencing *format_end, which means it's dereferencing one past the end of the format string that is passed to it. This is normally not how buffers are used in C: normally, the pointer to the end of a buffer is intended to point "one past" the last byte of the buffer, and is not intended to be dereferenced. If the intent here is that one should call doprnt with the pattern (doprnt (A, ASIZE, B, B + BSIZE - 1, AP)) then I suggest that the point be made clearly in doprnt's comment, as part of doprnt's API, to prevent future confusion in this area. From unknown Sat Jun 21 10:39:04 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Paul Eggert Subject: bug#8545: closed (Re: issues with recent doprnt-related changes) Message-ID: References: <4DB50AB9.6060100@cs.ucla.edu> X-Gnu-PR-Message: they-closed 8545 X-Gnu-PR-Package: emacs Reply-To: 8545@debbugs.gnu.org Date: Thu, 28 Apr 2011 05:51:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1303969863-20497-1" This is a multi-part message in MIME format... ------------=_1303969863-20497-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #8545: issues with recent doprnt-related changes which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 8545@debbugs.gnu.org. --=20 8545: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D8545 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1303969863-20497-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 8545-done) by debbugs.gnu.org; 28 Apr 2011 05:51:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFK7x-0005KN-0v for submit@debbugs.gnu.org; Thu, 28 Apr 2011 01:51:01 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFK7v-0005K9-K0 for 8545-done@debbugs.gnu.org; Thu, 28 Apr 2011 01:51:00 -0400 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QFK7p-0000de-I3; Thu, 28 Apr 2011 01:50:53 -0400 Date: Thu, 28 Apr 2011 01:50:53 -0400 Message-Id: From: Eli Zaretskii To: Paul Eggert In-reply-to: <4DB8ABEA.3080503@cs.ucla.edu> (message from Paul Eggert on Wed, 27 Apr 2011 16:51:06 -0700) Subject: Re: issues with recent doprnt-related changes References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB65FF1.5010003@cs.ucla.edu> <83aafb8p4a.fsf@gnu.org> <4DB8ABEA.3080503@cs.ucla.edu> X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: 8545-done Cc: 8545-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > Date: Wed, 27 Apr 2011 16:51:06 -0700 > From: Paul Eggert > CC: 8545@debbugs.gnu.org > > >> A quick second scan found a minor bug in size parsing: the > >> expression "n >= SIZE_MAX / 10" should be "n > SIZE_MAX / 10". > > > > When they get to messages as long as SIZE_MAX, let them sue me for > > taking away one byte. > > It's not a question of saving space at run-time. It's a question of > helping the reader. The reader is left wondering: why is that ">=" > there? The reader will be wondering with ">" as well. There's a comment about checking for overflow which should be a good hint, especially since SIZE_MAX is compared against. > And why is there another test "n * 10 > SIZE_MAX - (fmt[1] - > '0')" that always returns 0, no matter what? ??? What happens if n*10 is SIZE_MAX-1 and fmt[1] is '2'? Is the result still zero? > /* Avoid int overflow, because many sprintfs seriously mess up > with widths or precisions greater than INT_MAX. Avoid size_t > overflow, since our counters use size_t. This test is slightly > conservative, for speed and simplicity. */ > if (n >= min (INT_MAX, SIZE_MAX) / 10) > error ("Format width or precision too large"); Sorry, I don't see how this is clearer. The current code after the test is built out of the same building blocks as the test, and therefore the intent and the details of the test are easier to understand than with your variant, which perhaps is mathematically and numerically equivalent, but makes the code reading _harder_ because it severs the syntactical connection between the two. > > "MOST_POSITIVE_FIXNUM + 1" is too much, since MOST_POSITIVE_FIXNUM > > should be able to cover the terminating null character in Emacs. > > Why? Emacs size fields count the bytes in the string, and does not > count the terminating null byte (which is not part of the string). That's not what I know. String positions are zero-based and extend to include the terminating null character. See the relevant parts of the display engine code. > * doprnt invokes strlen to find the length of the format. The > vsnprintf code didn't need to do that: it traversed the format once. > Surely it shouldn't be hard to change doprnt so that it traverses > the format once rather than twice. doprnt is invoked in the context of displaying an error message that throws to top level, and so it doesn't need to be optimized (which will surely make the code more complex and error-prone, and its maintenance harder). > * Sometimes verror will incorrectly truncate a string, even when there > is plenty of memory. verror might call doprnt (buffer, SIZE, m, m + > mlen, ap), and doprnt might discover that a multibyte character is > chopped in half at the end of the output buffer, and might return > (say) SIZE - 2. verror will incorrectly conclude that the output > was just fine, but it wasn't complete. Not an issue, what with the initial buffer size you enlarged to 4000. I needed to artificially lower it to just 2 dozen bytes, just to see the recovery code in action. If someone wants to display a 4001-byte message that ends with a multibyte non-ASCII character, let them be punished for not knowing how to write concisely. > * verror might invoke doprnt two or more times, which means that > doprnt will traverse ap twice. This does not work in general; the C > standard is quite clear that the behavior is undefined in this case. Are there any platforms supported by Emacs where this actually happens? If not, let's forget about this issue until it hits us. I'm closing this bug. We are already well past any real problems, and invested too much energy and efforts of two busy people on this tiny function, all because of your stubborn insistence on using a library function where it doesn't fit the bill. I hope you now have more respect for views and code of others in general, and mine in particular, so we won't need to go through this painful experience again in the future. Let's move on; I still need to work on the bidirectional display of overlay strings and display properties, a job that was already delayed by several precious days due to these disputes and the gratuitous work on the code that should have been left alone in the first place. ------------=_1303969863-20497-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 25 Apr 2011 05:47:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEEdR-0004PJ-QA for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:47:02 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEEdP-0004Op-SU for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:47:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEEdJ-0000yv-RZ for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:46:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:42980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEEdJ-0000yq-Q4 for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:46:53 -0400 Received: from eggs.gnu.org ([140.186.70.92]:34848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEEdI-0003LV-Ua for bug-gnu-emacs@gnu.org; Mon, 25 Apr 2011 01:46:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEEdH-0000yZ-Oi for bug-gnu-emacs@gnu.org; Mon, 25 Apr 2011 01:46:52 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:57012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEEdH-0000xq-Fb; Mon, 25 Apr 2011 01:46:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id A617B39E80E0; Sun, 24 Apr 2011 22:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHaWohnIK7vt; Sun, 24 Apr 2011 22:46:42 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 19A6639E8082; Sun, 24 Apr 2011 22:46:42 -0700 (PDT) Message-ID: <4DB50AB9.6060100@cs.ucla.edu> Date: Sun, 24 Apr 2011 22:46:33 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: issues with recent doprnt-related changes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.7 (----) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.7 (----) This is a followup to Bug#8435. Eli invited me to review the recent doprnt-related changes, so here's a quick review: * doprnt returns size_t. But Stefan wrote that he prefers sizes to be signed values, and doprnt always returns a value that can fit in EMACS_INT. So shouldn't doprnt return EMACS_INT, as it did before? * doprnt supports only a small subset of the standard printf formats, but this subset is not documented. It's unclear what the subset is. Or it's a superset of the subset, with %S and %l? Anyway, this should be documented clearly in the lead comment. * I suggest that every feature in doprnt be a feature that is actually needed and used; this will simplify maintainance. * Format strings never include embedded null bytes, so there's no need for doprnt to support that. * If the format string is too long, the alloca inside doprnt will crash Emacs on some hosts. I suggest removing the alloca, instituting a fixed size limit on format specifiers, and documenting that limit. Since user code cannot ever supply one of these formats, that should be good enough. * The width features of doprnt (e.g., %25s) are never used. That part of the code is still buggy; please see some comments below. I suggest removing it entirely; this will simplify things. But if not: - doprnt mishandles format specifications such as %0.0.0d. It passes them off to printf, and this results in undefined behavior, near as I can tell. - doprnt uses atoi (&fmtcpy[1]), but surely this isn't right if there are flags such as '-'. - Quite possibly there are other problems in this area, but I didn't want to spend further time reviewing a never-used feature. * In this code, in verror: used = doprnt (buffer, size, m, m + mlen, ap); /* Note: the -1 below is because `doprnt' returns the number of bytes excluding the terminating null byte, and it always terminates with a null byte, even when producing a truncated message. */ if (used < size - 1) break; I don't see the reason for the "- 1". If you replace this with: used = doprnt (buffer, size, m, m + mlen, ap); if (used < size) break; the code should still work, because, when used < size, the buffer should be properly null-terminated. If it isn't then there's something wrong with doprnt, no? * In this code, in verror: else if (size < size_max - 1) size = size_max - 1; there's no need for the "- 1"s. Just use this: else if (size < size_max) size = size_max; * This code in verror: if (buffer == buf) buffer = (char *) xmalloc (size); else buffer = (char *) xrealloc (buffer, size); uses xrealloc, which is unnecessarily expensive, as it may copy the buffer's contents even though they are entirely garbage here. Use this instead, to avoid the useless copy: if (buffer != buf) xfree (buffer); buffer = (char *) xmalloc (size); ------------=_1303969863-20497-1-- From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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 06:12: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: To: Paul Eggert Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130397106322306 (code B ref 8545); Thu, 28 Apr 2011 06:12:01 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 06:11:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFKRK-0005nj-FR for submit@debbugs.gnu.org; Thu, 28 Apr 2011 02:11:02 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFKRJ-0005nC-6d for 8545@debbugs.gnu.org; Thu, 28 Apr 2011 02:11:01 -0400 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QFKRD-0001nu-So; Thu, 28 Apr 2011 02:10:55 -0400 Date: Thu, 28 Apr 2011 02:10:55 -0400 Message-Id: From: Eli Zaretskii In-reply-to: <4DB8FB35.5090205@cs.ucla.edu> (message from Paul Eggert on Wed, 27 Apr 2011 22:29:25 -0700) 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> <4DB8FB35.5090205@cs.ucla.edu> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > Date: Wed, 27 Apr 2011 22:29:25 -0700 > From: Paul Eggert > CC: lekktu@gmail.com, 8545@debbugs.gnu.org > > On 04/27/11 22:15, Eli Zaretskii wrote: > > As I explain in another message, we _can_ dereference this invalid > > pointer. > > Sorry, I'm not quite following, since I'm not sure what > the "another message" refers to. If you didn't receive it, you will find it filed in the bug tracker. > Hmm, perhaps you're talking about this pattern in the code? > > while (fmt < format_end) > { ... fmt++ ... } > switch (*fmt++) Yes, the loop (which increments the pointer more than once), the reference with postincrement in the switch statement, and the following dereference in fmt[-1] in the call to `error'. > Here, the code is dereferencing *format_end, > which means it's dereferencing one past the end of the > format string that is passed to it. No, it can dereference *(format_end+1). > If the intent here is that one should call doprnt with > the pattern (doprnt (A, ASIZE, B, B + BSIZE - 1, AP)) then > I suggest that the point be made clearly in doprnt's comment, > as part of doprnt's API, to prevent future confusion in > this area. No, it should be called as B+BSIZE. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert 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 06:44: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: To: Eli Zaretskii Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130397298825357 (code B ref 8545); Thu, 28 Apr 2011 06:44:02 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 06:43:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFKwO-0006aw-0c for submit@debbugs.gnu.org; Thu, 28 Apr 2011 02:43:08 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFKwK-0006aM-Qt for 8545@debbugs.gnu.org; Thu, 28 Apr 2011 02:43:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 2E44839E80FA; Wed, 27 Apr 2011 23:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpD52e4XcYE9; Wed, 27 Apr 2011 23:42:58 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 9C17039E8082; Wed, 27 Apr 2011 23:42:58 -0700 (PDT) Message-ID: <4DB90C71.6060804@cs.ucla.edu> Date: Wed, 27 Apr 2011 23:42:57 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> <4DB8FB35.5090205@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 04/27/11 23:10, Eli Zaretskii wrote: > No, it can dereference *(format_end+1). > >> If the intent here is that one should call doprnt with >> the pattern (doprnt (A, ASIZE, B, B + BSIZE - 1, AP)) then >> I suggest that the point be made clearly in doprnt's comment, >> as part of doprnt's API, to prevent future confusion in >> this area. > > No, it should be called as B+BSIZE. OK, but format_end == B + BSIZE. So if doprnt (A, ASIZE, B, B + BSIZE, AP) can dereference format_end + 1, this means doprnt can access B[BSIZE + 1], which means that B should point to a char array of at least BSIZE + 2 bytes. Normally, B is a C-language string literal such as "abc%d", and BSIZE is the length of the string, which means there is potential trouble because normally code should not try to read the byte that follows the null byte at the end of the string. I expect that the cases where doprnt actually accesses B[BSIZE + 1] are rare, and don't currently happen in practice; still, this is a confusing area and whatever constraints are actually placed on doprnt's caller should be made clear in the doprnt documentation, so that others are warned about the situation and don't make the mistake of passing formats that could cause problems. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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 07:27: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: To: Paul Eggert Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13039755962034 (code B ref 8545); Thu, 28 Apr 2011 07:27:02 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 07:26:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFLcR-0000Wl-Jh for submit@debbugs.gnu.org; Thu, 28 Apr 2011 03:26:35 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFLcP-0000WY-JT for 8545@debbugs.gnu.org; Thu, 28 Apr 2011 03:26:34 -0400 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QFLcK-0006Sx-Bc; Thu, 28 Apr 2011 03:26:28 -0400 Date: Thu, 28 Apr 2011 03:26:28 -0400 Message-Id: From: Eli Zaretskii In-reply-to: <4DB90C71.6060804@cs.ucla.edu> (message from Paul Eggert on Wed, 27 Apr 2011 23:42:57 -0700) 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> <4DB8FB35.5090205@cs.ucla.edu> <4DB90C71.6060804@cs.ucla.edu> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > Date: Wed, 27 Apr 2011 23:42:57 -0700 > From: Paul Eggert > CC: lekktu@gmail.com, 8545@debbugs.gnu.org > > OK, but format_end == B + BSIZE. > So if doprnt (A, ASIZE, B, B + BSIZE, AP) can dereference format_end + 1, > this means doprnt can access B[BSIZE + 1], which means that > B should point to a char array of at least BSIZE + 2 bytes. With the original code, that was the case, yes. But that is why I forcibly reset fmt to point to format_end: to avoid dereferencing past the end of the array. If you are saying that such invalid dereferencing can still happen, please show how is that possible, with the code that is now in the repository. > Normally, B is a C-language string literal such as "abc%d", > and BSIZE is the length of the string, which means > there is potential trouble because normally code > should not try to read the byte that follows the null > byte at the end of the string. That trouble shouldn't happen with the code in the repository. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert 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 07:55: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: To: Eli Zaretskii Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13039772784408 (code B ref 8545); Thu, 28 Apr 2011 07:55:02 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 07:54:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFM3Z-000192-V0 for submit@debbugs.gnu.org; Thu, 28 Apr 2011 03:54:38 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFM3X-00018r-Vo for 8545@debbugs.gnu.org; Thu, 28 Apr 2011 03:54:36 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 8350D39E80FA; Thu, 28 Apr 2011 00:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbH7HvLLV9Ei; Thu, 28 Apr 2011 00:54:30 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 1873139E8082; Thu, 28 Apr 2011 00:54:30 -0700 (PDT) Message-ID: <4DB91D2D.5080008@cs.ucla.edu> Date: Thu, 28 Apr 2011 00:54:21 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> <4DB8FB35.5090205@cs.ucla.edu> <4DB90C71.6060804@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 04/28/11 00:26, Eli Zaretskii wrote: > If you are saying that such invalid dereferencing can still happen, > please show how is that possible, with the code that is now in the > repository. Sorry, I misunderstood your earlier comment to mean that doprnt can now compute *(format_end+1). If all that doprnt does is compute *format_end (or format_end+1 without dereferencing format_end+1), and if the documentation notes that format_end must point to a character (format_end cannot point to one-past-the-buffer-end, which is what I expected), then that part's OK. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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 11:15: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: To: Paul Eggert Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130398926321733 (code B ref 8545); Thu, 28 Apr 2011 11:15:02 +0000 Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 11:14:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFPAs-0005eU-Io for submit@debbugs.gnu.org; Thu, 28 Apr 2011 07:14:23 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFPAq-0005eI-8Y for 8545@debbugs.gnu.org; Thu, 28 Apr 2011 07:14:20 -0400 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QFPAk-00082P-JM; Thu, 28 Apr 2011 07:14:14 -0400 Date: Thu, 28 Apr 2011 07:14:14 -0400 Message-Id: From: Eli Zaretskii In-reply-to: <4DB91D2D.5080008@cs.ucla.edu> (message from Paul Eggert on Thu, 28 Apr 2011 00:54:21 -0700) 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> <4DB8FB35.5090205@cs.ucla.edu> <4DB90C71.6060804@cs.ucla.edu> <4DB91D2D.5080008@cs.ucla.edu> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > Date: Thu, 28 Apr 2011 00:54:21 -0700 > From: Paul Eggert > CC: lekktu@gmail.com, 8545@debbugs.gnu.org > > If all that doprnt does is compute *format_end (or format_end+1 > without dereferencing format_end+1), and if the documentation > notes that format_end must point to a character > (format_end cannot point to one-past-the-buffer-end, > which is what I expected), then that part's OK. Yes, that's how things are. format_end points to the last byte of the buffer passed to doprnt. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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: To: Paul Eggert Cc: 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130407585922455 (code B ref 8545); Fri, 29 Apr 2011 11:18:02 +0000 Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 11:17:39 +0000 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 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 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) 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) Date: Fri, 29 Apr 2011 14:16:57 +0300 From: Eli Zaretskii In-reply-to: <4DB9E5FF.9020506@cs.ucla.edu> X-012-Sender: halo1@inter.net.il 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> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > 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 ;-) From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Richard Stallman 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 12:29: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: To: Paul Eggert Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Reply-To: rms@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130408012331576 (code B ref 8545); Fri, 29 Apr 2011 12:29:01 +0000 Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 12:28:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFmoM-0008DE-Pk for submit@debbugs.gnu.org; Fri, 29 Apr 2011 08:28:43 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFmoK-0008D2-NL for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 08:28:41 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QFmoF-0003nE-7o; Fri, 29 Apr 2011 08:28:35 -0400 Date: Fri, 29 Apr 2011 08:28:35 -0400 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman In-reply-to: <4DB8DAF8.7070408@cs.ucla.edu> (message from Paul Eggert on Wed, 27 Apr 2011 20:11:52 -0700) 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> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) No, format_end is already pointing after the object; the object's size is format_end - format. So format_end + 1 might not be a valid pointer. 20 years ago,, Emacs allocated an extra byte with a null character after the end of every string or buffer. If that is still true then this pointer actually is valid. But it doesn't matter anyway, for reasons described below. Yes. A portable C program is not allowed to create a pointer that doesn't point to an object, Our C programs are allowed to create any sort of pointer we want them to. ISO has no authority over us. We are concerned with standards insofar as they matter in practice for the convenience and reliability of our software. Thus, the question that matters to us is whether a construct is going to cause a problem on the plausibke platforms we will want to support. That does not include all theoretical ISO C implementations. Yes. To take an extreme example, some architectures can compute a pointer only by using a special pointer register, and the register's contents are always checked for validity, even if you don't dereference the pointer. They are outside GNU's design range of targets. If you assign i = INT_MAX + 1, the resulting behavior is undefined. The result is INT_MIN. We don't try to support any theoretical machine where this would not be so. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert 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 14:42: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130408811611289 (code B ref 8545); Fri, 29 Apr 2011 14:42:01 +0000 Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 14:41:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFotI-0002w2-BS for submit@debbugs.gnu.org; Fri, 29 Apr 2011 10:41:56 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFotF-0002vp-U4 for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 10:41:54 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 7722139E8109; Fri, 29 Apr 2011 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWl--vbEzc+t; Fri, 29 Apr 2011 07:41:48 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 1459639E80F7; Fri, 29 Apr 2011 07:41:48 -0700 (PDT) Message-ID: <4DBACE24.5080803@cs.ucla.edu> Date: Fri, 29 Apr 2011 07:41:40 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> <83d3k571ee.fsf@gnu.org> In-Reply-To: <83d3k571ee.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 04/29/11 04:16, Eli Zaretskii wrote: > 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 Yes, that would be fine. I hadn't thought of that possibility. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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 19:36: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: To: Paul Eggert Cc: 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13041057594385 (code B ref 8545); Fri, 29 Apr 2011 19:36:02 +0000 Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 19:35:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFtTq-00018g-0J for submit@debbugs.gnu.org; Fri, 29 Apr 2011 15:35:58 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFtTm-00018R-KB for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 15:35:55 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LKF00C00I51SD00@a-mtaout21.012.net.il> for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 22:35:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.150.132]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKF00CAQIFMP5A0@a-mtaout21.012.net.il>; Fri, 29 Apr 2011 22:35:47 +0300 (IDT) Date: Fri, 29 Apr 2011 22:35:48 +0300 From: Eli Zaretskii In-reply-to: <4DBACE24.5080803@cs.ucla.edu> X-012-Sender: halo1@inter.net.il Message-id: <83zkn86eaz.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> <83d3k571ee.fsf@gnu.org> <4DBACE24.5080803@cs.ucla.edu> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Fri, 29 Apr 2011 07:41:40 -0700 > From: Paul Eggert > CC: 8545@debbugs.gnu.org > > On 04/29/11 04:16, Eli Zaretskii wrote: > > 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 > > Yes, that would be fine. I installed such a change. Btw, none of the platforms currently defines HAVE_LONG_LONG_INT or HAVE_UNSIGNED_LONG_LONG_INT, AFAICS. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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 19:57: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: To: rms@gnu.org Cc: lekktu@gmail.com, 8545@debbugs.gnu.org, eggert@cs.ucla.edu Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13041070166236 (code B ref 8545); Fri, 29 Apr 2011 19:57:02 +0000 Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 19:56:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFto7-0001cX-OK for submit@debbugs.gnu.org; Fri, 29 Apr 2011 15:56:55 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFto5-0001cL-TC for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 15:56:54 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LKF00500IFW7C00@a-mtaout22.012.net.il> for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 22:56:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.150.132]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKF00308JED1RU0@a-mtaout22.012.net.il>; Fri, 29 Apr 2011 22:56:38 +0300 (IDT) Date: Fri, 29 Apr 2011 22:56:39 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83wric6dc8.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> <4DB8DAF8.7070408@cs.ucla.edu> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Fri, 29 Apr 2011 08:28:35 -0400 > From: Richard Stallman > Cc: lekktu@gmail.com, 8545@debbugs.gnu.org > > No, format_end is already pointing after the object; > the object's size is format_end - format. So > format_end + 1 might not be a valid pointer. > > 20 years ago, Emacs allocated an extra byte with a null character > after the end of every string or buffer. 20 years later, we still do that for strings, but (AFAICS) not for buffers. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert 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 20:33: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13041091589339 (code B ref 8545); Fri, 29 Apr 2011 20:33:02 +0000 Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 20:32:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFuMf-0002Qa-O1 for submit@debbugs.gnu.org; Fri, 29 Apr 2011 16:32:37 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFuMd-0002QO-W7 for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 16:32:36 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 51FEB39E8106; Fri, 29 Apr 2011 13:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLblpumboX3D; Fri, 29 Apr 2011 13:32:30 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id EDE9C39E80F7; Fri, 29 Apr 2011 13:32:29 -0700 (PDT) Message-ID: <4DBB205D.6050406@cs.ucla.edu> Date: Fri, 29 Apr 2011 13:32:29 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 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> <83d3k571ee.fsf@gnu.org> <4DBACE24.5080803@cs.ucla.edu> <83zkn86eaz.fsf@gnu.org> In-Reply-To: <83zkn86eaz.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.2 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) On 04/29/11 12:35, Eli Zaretskii wrote: > none of the platforms currently defines HAVE_LONG_LONG_INT or > HAVE_UNSIGNED_LONG_LONG_INT, AFAICS. It's done automatically, by 'configure'. HAVE_LONG_LONG_INT is 1 on all the platforms I regularly use, e.g., x86 GNU/Linux. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert 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 23:50: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: To: rms@gnu.org Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130412097032110 (code B ref 8545); Fri, 29 Apr 2011 23:50:02 +0000 Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 23:49:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFxRB-0008Lr-Bc for submit@debbugs.gnu.org; Fri, 29 Apr 2011 19:49:29 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QFxR9-0008Lf-3c for 8545@debbugs.gnu.org; Fri, 29 Apr 2011 19:49:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 7BF0839E8106; Fri, 29 Apr 2011 16:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU65Fyozg0+U; Fri, 29 Apr 2011 16:49:20 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id E382839E80F2; Fri, 29 Apr 2011 16:49:20 -0700 (PDT) Message-ID: <4DBB4E80.2020102@cs.ucla.edu> Date: Fri, 29 Apr 2011 16:49:20 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.2 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) On 04/29/11 05:28, Richard Stallman wrote: > We are concerned with standards insofar as they matter in practice > for the convenience and reliability of our software. Yes, of course, I should have made that clearer. Standards are our tools, not our masters. >> If you assign i = INT_MAX + 1, the resulting behavior is undefined. > > The result is INT_MIN. We don't try to support any theoretical machine > where this would not be so. Those machines used to be theoretical, but they're in common use now. Practical C code can no longer assume that integers always wrap around when doing integer arithmetic. For example: long foo (char *p, int i) { return &p[i + 1] - &p[i]; } On typical hosts where int is 32 bits, and long and char * are both 64 bits, most compilers optimize that "return" statement to "return 1;", even when I is INT_MAX and I + 1 therefore overflows. These compilers are therefore rejecting the notion that INT_MAX + 1 must always equal INT_MIN. Although FOO is contrived, a lot of complicated code in Emacs mixes int and long and pointer arithmetic, and it's inevitable that compilers are doing optimizations like the above when they compile Emacs. We cannot simply declare that INT_MAX + 1 must always be INT_MIN, because that's not how compilers actually work these days. What we need is good advice for programmers in this area, so that they can write C code that is portable in practice. This advice shouldn't be too conservative, because that would discourage useful programs. Nor should it be too loosey-goosey, because that would encourage buggy programs. Nor should it be complicated, because that would confuse people and waste their time. It is not easy to come up with advice that satisfies all three constraints. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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: Sat, 30 Apr 2011 09:00:04 +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: To: Paul Eggert Cc: 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130415400014880 (code B ref 8545); Sat, 30 Apr 2011 09:00:04 +0000 Received: (at 8545) by debbugs.gnu.org; 30 Apr 2011 09:00:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QG61w-0003rw-Dn for submit@debbugs.gnu.org; Sat, 30 Apr 2011 05:00:00 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QG61u-0003rj-Gv for 8545@debbugs.gnu.org; Sat, 30 Apr 2011 04:59:59 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LKG00C00JEU7S00@a-mtaout22.012.net.il> for 8545@debbugs.gnu.org; Sat, 30 Apr 2011 11:59:16 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.185.101]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKG00AR5JMRW5F0@a-mtaout22.012.net.il>; Sat, 30 Apr 2011 11:59:16 +0300 (IDT) Date: Sat, 30 Apr 2011 11:59:18 +0300 From: Eli Zaretskii In-reply-to: <4DBB205D.6050406@cs.ucla.edu> X-012-Sender: halo1@inter.net.il Message-id: <83r58k5d3t.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> <83d3k571ee.fsf@gnu.org> <4DBACE24.5080803@cs.ucla.edu> <83zkn86eaz.fsf@gnu.org> <4DBB205D.6050406@cs.ucla.edu> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Fri, 29 Apr 2011 13:32:29 -0700 > From: Paul Eggert > CC: 8545@debbugs.gnu.org > > On 04/29/11 12:35, Eli Zaretskii wrote: > > none of the platforms currently defines HAVE_LONG_LONG_INT or > > HAVE_UNSIGNED_LONG_LONG_INT, AFAICS. > > It's done automatically, by 'configure'. You are right, I didn't look in some of the possible places. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Richard Stallman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Apr 2011 21:05: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: To: Paul Eggert Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Reply-To: rms@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130419744217924 (code B ref 8545); Sat, 30 Apr 2011 21:05:02 +0000 Received: (at 8545) by debbugs.gnu.org; 30 Apr 2011 21:04:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGHKb-0004f0-1Q for submit@debbugs.gnu.org; Sat, 30 Apr 2011 17:04:01 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGHKX-0004en-Qf for 8545@debbugs.gnu.org; Sat, 30 Apr 2011 17:03:58 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QGHKN-0008I1-9A; Sat, 30 Apr 2011 17:03:47 -0400 Date: Sat, 30 Apr 2011 17:03:47 -0400 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman In-reply-to: <4DBB4E80.2020102@cs.ucla.edu> (message from Paul Eggert on Fri, 29 Apr 2011 16:49:20 -0700) 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> <4DBB4E80.2020102@cs.ucla.edu> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) >> If you assign i = INT_MAX + 1, the resulting behavior is undefined. > > The result is INT_MIN. We don't try to support any theoretical machine > where this would not be so. Those machines used to be theoretical, but they're in common use now. I assumed we were talking about type `int', but you did not explicitly say so. Touché -- but that just means we are talking at cross purposes. What I said about addition on type int is still valid. printf ("%d", INT_MAX+1); will output INT_MIN. Practical C code can no longer assume that integers always wrap around when doing integer arithmetic. I think that is the wrong interpretation of the facts. long foo (char *p, int i) { return &p[i + 1] - &p[i]; } On typical hosts where int is 32 bits, and long and char * are both 64 bits, most compilers optimize that "return" statement to "return 1;", even when I is INT_MAX and I + 1 therefore overflows. These compilers are therefore rejecting the notion that INT_MAX + 1 must always equal INT_MIN. i+1 is computed as an integer, but then it gets converted to a long. What happens here seems to be an issue about type conversion combined with addition -- not addition itself. These compilers are taking a strange liberty. Why isn't that a bug? -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Jason Rumney Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 May 2011 04:26: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: To: Paul Eggert Cc: lekktu@gmail.com, 8545@debbugs.gnu.org, rms@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130422396121976 (code B ref 8545); Sun, 01 May 2011 04:26:01 +0000 Received: (at 8545) by debbugs.gnu.org; 1 May 2011 04:26:01 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGOEL-0005iM-1x for submit@debbugs.gnu.org; Sun, 01 May 2011 00:26:01 -0400 Received: from mail-px0-f169.google.com ([209.85.212.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGOEJ-0005i9-3V for 8545@debbugs.gnu.org; Sun, 01 May 2011 00:25:59 -0400 Received: by pxi9 with SMTP id 9so1635019pxi.0 for <8545@debbugs.gnu.org>; Sat, 30 Apr 2011 21:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version:content-type; bh=5ET9mmTKhC6Jdiec/SEoOGHWjKM6o7hwqNI1wxCYC8w=; b=qXhNl8AcqvcTM43Tqsua57jdazkafC6rZOSAZqfTXxOwEC/iF3JG1q7P6y0Owgjy7R mf/fgMJULu1qMaeitUQi2mxYX72bhH4NE7ekOw4xXYM+Fmd8oUrXXi0NT953cmkfnzXh 8oVr0K2S6u8nKC46q9HeoLrwhEi/Enxa3OUXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=p2oMo9RWaCZyaPuzqYOZw9aJ615e1nAQAzR3Y84Hp1nyaTB+GKpb/NP9oD9VKF81VB Wzq4UMB8/L+jUHsBhcJsVrVsw8XqooaSb6Mfbb7TNqR8r2TV1dcKH6fW6LgjrG4iMbLG n7WzJ1rC975Gc1yhNPpXfMK59xMNQX1OdY8iY= Received: by 10.68.41.234 with SMTP id i10mr7789477pbl.345.1304223953211; Sat, 30 Apr 2011 21:25:53 -0700 (PDT) Received: from home.jasonrumney.net ([180.75.3.117]) by mx.google.com with ESMTPS id m5sm2946432pbh.70.2011.04.30.21.25.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Apr 2011 21:25:51 -0700 (PDT) Received: by home.jasonrumney.net (Postfix, from userid 1000) id BDE983773; Sun, 1 May 2011 12:25:45 +0800 (MYT) From: Jason Rumney 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> <4DBB4E80.2020102@cs.ucla.edu> Date: Sun, 01 May 2011 12:25:45 +0800 In-Reply-To: <4DBB4E80.2020102@cs.ucla.edu> (Paul Eggert's message of "Fri, 29 Apr 2011 16:49:20 -0700") Message-ID: <87vcxvjbcm.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) Paul Eggert writes: > On 04/29/11 05:28, Richard Stallman wrote: > >> We are concerned with standards insofar as they matter in practice >> for the convenience and reliability of our software. > > Yes, of course, I should have made that clearer. Standards are our > tools, not our masters. > >>> If you assign i = INT_MAX + 1, the resulting behavior is undefined. >> >> The result is INT_MIN. We don't try to support any theoretical machine >> where this would not be so. > > long > foo (char *p, int i) > { > return &p[i + 1] - &p[i]; > } > > On typical hosts where int is 32 bits, and long and char * are > both 64 bits, most compilers optimize that "return" statement > to "return 1;", even when I is INT_MAX and I + 1 therefore > overflows. That does not mean that INT_MAX + 1 is undefined. You are also involving implicit casts here. Exactly where those casts happen is what is undefined. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 May 2011 05:42: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: To: rms@gnu.org Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130422850728259 (code B ref 8545); Sun, 01 May 2011 05:42:02 +0000 Received: (at 8545) by debbugs.gnu.org; 1 May 2011 05:41:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGPPf-0007Lk-Hy for submit@debbugs.gnu.org; Sun, 01 May 2011 01:41:47 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGPPd-0007LY-Dn for 8545@debbugs.gnu.org; Sun, 01 May 2011 01:41:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E07A339E80F8; Sat, 30 Apr 2011 22:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEJ7uugXUZMp; Sat, 30 Apr 2011 22:41:39 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 5EDBA39E80F2; Sat, 30 Apr 2011 22:41:39 -0700 (PDT) Message-ID: <4DBCF292.4030002@cs.ucla.edu> Date: Sat, 30 Apr 2011 22:41:38 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> <4DBB4E80.2020102@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 04/30/11 14:03, Richard Stallman wrote: > long > foo (char *p, int i) > { > return &p[i + 1] - &p[i]; > } > ... > i+1 is computed as an integer, but then it gets converted to a long. Unfortunately that doesn't explain FOO's behavior. If i+1 is computed as an int and if wraparound is required, then when i is INT_MAX, i+1 must be INT_MIN. (FOO does not convert i+1 to long; but even if it did, INT_MIN's value would be unchanged by that conversion.) If p is pointing into a large array, &p[INT_MIN] and &p[INT_MAX] can both be valid addresses, and in that case foo (p, INT_MAX) would have to yield -2**32 + 1 on a typical 64-bit host where signed integer arithmetic wrapped around. But in my experience no compiler does it that way. FOO always returns 1. > What happens here seems to be an issue about type conversion combined > with addition -- not addition itself. I'm afraid not. First, FOO doesn't have any type conversions. If I is an int, A[I] doesn't convert I to any other type; it simply uses I's value without conversion. Second, it's easy to construct an example that involves only "int": int bar (int i) { return i < i + 1; } With many compilers, BAR always returns 1, even when i == INT_MAX. > These compilers are taking a strange liberty. > Why isn't that a bug? Well, for starters, most programmers *expect* FOO to return 1, and similarly for BAR. Why would a programmer file a bug report when the program is behaving as expected? > printf ("%d", INT_MAX+1); > will output INT_MIN. That's true for all systems I have ready access to, yes. And I expect there are other cases where int arithmetic wraps around reliably. But there are many practical cases where it doesn't. We cannot simply advise programmers to assume that adding 1 to INT_MAX always results in INT_MIN, as that assumption is often incorrect nowadays. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 May 2011 05:57: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: To: Jason Rumney Cc: lekktu@gmail.com, 8545@debbugs.gnu.org, rms@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130422941429516 (code B ref 8545); Sun, 01 May 2011 05:57:01 +0000 Received: (at 8545) by debbugs.gnu.org; 1 May 2011 05:56:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGPeH-0007g1-SK for submit@debbugs.gnu.org; Sun, 01 May 2011 01:56:54 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGPeF-0007fp-QK for 8545@debbugs.gnu.org; Sun, 01 May 2011 01:56:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 31C0F39E80F8; Sat, 30 Apr 2011 22:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxgwXeISZyNy; Sat, 30 Apr 2011 22:56:45 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id AE00B39E80F2; Sat, 30 Apr 2011 22:56:45 -0700 (PDT) Message-ID: <4DBCF61D.50000@cs.ucla.edu> Date: Sat, 30 Apr 2011 22:56:45 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> <4DBB4E80.2020102@cs.ucla.edu> <87vcxvjbcm.fsf@gnu.org> In-Reply-To: <87vcxvjbcm.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 04/30/11 21:25, Jason Rumney wrote: > You are also > involving implicit casts here. Exactly where those casts happen is what > is undefined. I'm not sure what is meant here, as the program in question doesn't have any implicit arithmetic conversions (or at least, it doesn't on the typical 64-bit host I was talking about). > That does not mean that INT_MAX + 1 is undefined. It could well be that the exact expression "INT_MAX + 1" has well-defined behavior on all platforms we care about, and that it always returns INT_MIN. But I'm concerned about the more general issue, which is whether Emacs code can always assume that signed integer arithmetic wraps around. Unfortunately, there are many practical Emacs targets where it's incorrect to assume that. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Jason Rumney Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 May 2011 08:13: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: To: Paul Eggert Cc: lekktu@gmail.com, 8545@debbugs.gnu.org, rms@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13042375768505 (code B ref 8545); Sun, 01 May 2011 08:13:02 +0000 Received: (at 8545) by debbugs.gnu.org; 1 May 2011 08:12:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGRlv-0002D8-TG for submit@debbugs.gnu.org; Sun, 01 May 2011 04:12:56 -0400 Received: from mail-pv0-f172.google.com ([74.125.83.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGRlt-0002Cv-BM for 8545@debbugs.gnu.org; Sun, 01 May 2011 04:12:53 -0400 Received: by pvh1 with SMTP id 1so3139139pvh.3 for <8545@debbugs.gnu.org>; Sun, 01 May 2011 01:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version:content-type; bh=xbuIaWNidBBEG+0eMVGDyGLD9c0BgyIC2rybK6T4HZY=; b=ZMPT6YY0uLVAbUBVMB5nRdGP+17CH9QqUUoJQgYWBb39KmWnNIf4rmSNg89esEO/gW lKrF5YIQnTxLXi5yKJybAvhXZLzp0E63uqdw5bT2IhX94x+/lPgJ1VAFw2g4dLwmIwMr CHi4tgCpNRJMHBe46gJgcpamdCherLp5VDak8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=PmRVJK5/jOnRM50EEZd1y0/OVhT7ZNbou8XxhV08rWM8nxrKm1XD1nJeSVQSk3wtvH GGErrPfW23+6J8kSDeEbWsOXb78FRi1WWrVReNGvMsEqw3NWWK8yO2YPJCFqkeRBJ6GJ lB3f/p2Dmdh8pG7YXIIJL3uNXEWeVOKybq/3g= Received: by 10.142.151.17 with SMTP id y17mr2650125wfd.334.1304237567470; Sun, 01 May 2011 01:12:47 -0700 (PDT) Received: from home.jasonrumney.net ([180.75.3.117]) by mx.google.com with ESMTPS id k6sm5508374wfa.5.2011.05.01.01.12.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2011 01:12:46 -0700 (PDT) Received: by home.jasonrumney.net (Postfix, from userid 1000) id BF8103FE6; Sun, 1 May 2011 16:12:38 +0800 (MYT) From: Jason Rumney 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> <4DBB4E80.2020102@cs.ucla.edu> <87vcxvjbcm.fsf@gnu.org> <4DBCF61D.50000@cs.ucla.edu> Date: Sun, 01 May 2011 16:12:38 +0800 In-Reply-To: <4DBCF61D.50000@cs.ucla.edu> (Paul Eggert's message of "Sat, 30 Apr 2011 22:56:45 -0700") Message-ID: <87pqo2kfex.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) Paul Eggert writes: > I'm not sure what is meant here, as the program in question > doesn't have any implicit arithmetic conversions (or at least, > it doesn't on the typical 64-bit host I was talking about). It has implicit type conversion from int to char* and then to long. Whether those types are different from each other depends on the host machine, OS and compiler. That is what is undeterministic about your example, not the fact that in int arithmetic INT_MAX + 1 == INT_MIN. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 May 2011 11:03: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: To: Jason Rumney Cc: lekktu@gmail.com, 8545@debbugs.gnu.org, Paul Eggert , rms@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130424774424334 (code B ref 8545); Sun, 01 May 2011 11:03:02 +0000 Received: (at 8545) by debbugs.gnu.org; 1 May 2011 11:02:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGUPw-0006KR-46 for submit@debbugs.gnu.org; Sun, 01 May 2011 07:02:24 -0400 Received: from mail-out.m-online.net ([212.18.0.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGUPs-0006KE-LR for 8545@debbugs.gnu.org; Sun, 01 May 2011 07:02:21 -0400 Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 993C418005CE; Sun, 1 May 2011 13:02:13 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id 3DC7A1C000F8; Sun, 1 May 2011 13:02:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id 0EIA6Bpxe21a; Sun, 1 May 2011 13:02:14 +0200 (CEST) Received: from igel.home (ppp-88-217-115-33.dynamic.mnet-online.de [88.217.115.33]) by mail.mnet-online.de (Postfix) with ESMTP; Sun, 1 May 2011 13:02:13 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id 52197CA29C; Sun, 1 May 2011 13:02:13 +0200 (CEST) From: Andreas Schwab 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> <4DBB4E80.2020102@cs.ucla.edu> <87vcxvjbcm.fsf@gnu.org> <4DBCF61D.50000@cs.ucla.edu> <87pqo2kfex.fsf@gnu.org> X-Yow: Is a tattoo real, like a curb or a battleship? Or are we suffering in Safeway? Date: Sun, 01 May 2011 13:02:13 +0200 In-Reply-To: <87pqo2kfex.fsf@gnu.org> (Jason Rumney's message of "Sun, 01 May 2011 16:12:38 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Jason Rumney writes: > It has implicit type conversion from int to char* and then to long. The only implicit conversion in this function is from ptrdiff_t to long. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Richard Stallman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 May 2011 00:00:04 +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: To: Paul Eggert Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Reply-To: rms@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130429435428436 (code B ref 8545); Mon, 02 May 2011 00:00:04 +0000 Received: (at 8545) by debbugs.gnu.org; 1 May 2011 23:59:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGgXh-0007Ob-O3 for submit@debbugs.gnu.org; Sun, 01 May 2011 19:59:13 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGgXf-0007OP-Pn for 8545@debbugs.gnu.org; Sun, 01 May 2011 19:59:12 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QGgXa-0000Fo-BP; Sun, 01 May 2011 19:59:06 -0400 Date: Sun, 01 May 2011 19:59:06 -0400 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman In-reply-to: <4DBCF292.4030002@cs.ucla.edu> (message from Paul Eggert on Sat, 30 Apr 2011 22:41:38 -0700) 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> <4DBB4E80.2020102@cs.ucla.edu> <4DBCF292.4030002@cs.ucla.edu> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Second, it's easy to construct an example that involves only "int": int bar (int i) { return i < i + 1; } With many compilers, BAR always returns 1, even when i == INT_MAX. I see. This would break many constructions intended to test whether an operation did overflow. Is there any reliable way to test for that? -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 May 2011 00:24: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: To: rms@gnu.org Cc: lekktu@gmail.com, 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130429582830563 (code B ref 8545); Mon, 02 May 2011 00:24:01 +0000 Received: (at 8545) by debbugs.gnu.org; 2 May 2011 00:23:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGgvU-0007wu-5F for submit@debbugs.gnu.org; Sun, 01 May 2011 20:23:48 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGgvR-0007wh-IA for 8545@debbugs.gnu.org; Sun, 01 May 2011 20:23:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id D916739E80F8; Sun, 1 May 2011 17:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWUwu0Gs0TnC; Sun, 1 May 2011 17:23:39 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 3216039E8083; Sun, 1 May 2011 17:23:39 -0700 (PDT) Message-ID: <4DBDF989.8070500@cs.ucla.edu> Date: Sun, 01 May 2011 17:23:37 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> <4DBB4E80.2020102@cs.ucla.edu> <4DBCF292.4030002@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 05/01/11 16:59, Richard Stallman wrote: > This would break many constructions intended to test whether an > operation did overflow. Is there any reliable way to test for that? Yes. For example: int add_overflow (int a, int b) { if (b < 0) return a < INT_MIN - b; else return INT_MAX - b < a; } add_overflow (a, b) returns 1 if a + b would overflow. There are similar reliable tests for the other arithmetic operations. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 May 2011 20:25: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: To: rms@gnu.org Cc: 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130445426717963 (code B ref 8545); Tue, 03 May 2011 20:25:01 +0000 Received: (at 8545) by debbugs.gnu.org; 3 May 2011 20:24:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QHM8w-0004fg-Oy for submit@debbugs.gnu.org; Tue, 03 May 2011 16:24:26 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QHM8t-0004fU-LR for 8545@debbugs.gnu.org; Tue, 03 May 2011 16:24:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 2B9AF39E80F2; Tue, 3 May 2011 13:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7dyAHXGbCFv; Tue, 3 May 2011 13:24:16 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id C704B39E80B1; Tue, 3 May 2011 13:24:16 -0700 (PDT) Message-ID: <4DC06470.4050902@cs.ucla.edu> Date: Tue, 03 May 2011 13:24:16 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110421 Fedora/3.1.9-2.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 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> <4DBB4E80.2020102@cs.ucla.edu> <4DBCF292.4030002@cs.ucla.edu> <4DBDF989.8070500@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.2 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) >> There are similar reliable tests for the other arithmetic operations. > > Is this documented somewhere? Is there a list of the standard ways? CERT has something, here: https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow Although the principles in that memo are OK, the actual code is hard to read and its multiplication overflow checking is buggy. Here's something better, which I just now wrote. Also, please see Emacs Bug#8611 ; its patch uses code like the following. #include int add_overflow (int a, int b) { return (b < 0 ? a < INT_MIN - b : INT_MAX - b < a); } int subtract_overflow (int a, int b) { return (b < 0 ? INT_MAX + b < a : a < INT_MIN + b); } int unary_minus_overflow (int a) { return a < -INT_MAX; } int multiply_overflow (int a, int b) { return (b < 0 ? (a < 0 ? a < INT_MAX / b : b != -1 && INT_MIN / b < a) : (b != 0 && (a < 0 ? a < INT_MIN / b : INT_MAX / b < a))); } int quotient_overflow (int a, int b) { /* This does not check for division by zero. Add that if you like. */ return a < -INT_MAX && b == -1; } int remainder_overflow (int a, int b) { /* Mathematically the remainder should never overflow, but on x86-like hosts INT_MIN % -1 traps, and the C standard permits this. */ return quotient_overflow (a, b); } From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 May 2011 07:29: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130449410910841 (code B ref 8545); Wed, 04 May 2011 07:29:02 +0000 Received: (at 8545) by debbugs.gnu.org; 4 May 2011 07:28:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QHWVZ-0002oo-2k for submit@debbugs.gnu.org; Wed, 04 May 2011 03:28:29 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QHWVW-0002oW-Sg for 8545@debbugs.gnu.org; Wed, 04 May 2011 03:28:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 672B139E8108; Wed, 4 May 2011 00:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxxAM5iasiSP; Wed, 4 May 2011 00:28:19 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 3F7B239E80F8; Wed, 4 May 2011 00:28:19 -0700 (PDT) Message-ID: <4DC10012.8020809@cs.ucla.edu> Date: Wed, 04 May 2011 00:28:18 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> <83d3k571ee.fsf@gnu.org> In-Reply-To: <83d3k571ee.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 04/29/11 04:16, Eli Zaretskii wrote: > I guess so, yes. I would like to have other opinions, though, so I > will start a new thread on emacs-devel about that. It seems from that discussion that strings can contain MOST_POSITIVE_FIXNUM bytes. Also, that va_arg bug really needs fixing. So I plan to install the following patch after some more testing. This assumes va_copy exists, which may affect the Windows port, but a one-line macro should suffice if it doesn't have va_copy already. === modified file 'ChangeLog' --- ChangeLog 2011-05-04 06:11:49 +0000 +++ ChangeLog 2011-05-04 07:19:21 +0000 @@ -1,5 +1,9 @@ 2011-05-04 Paul Eggert + Use C99's va_copy to avoid undefined behavior on x86-64 GNU/Linux. + * Makefile.in (GNULIB_MODULES): Add stdarg, for va_copy. + * lib/stdarg.in.h, m4/stdarg.m4: New files, from gnulib. + * Makefile.in (GNULIB_TOOL_FLAG): Add --conditional-dependencies. This new gnulib-tool option saves 'configure' the trouble of checking for strtoull when strtoumax exists. === modified file 'Makefile.in' --- Makefile.in 2011-05-04 06:11:49 +0000 +++ Makefile.in 2011-05-04 07:19:21 +0000 @@ -333,7 +333,7 @@ GNULIB_MODULES = \ careadlinkat crypto/md5 dtoastr filemode getloadavg getopt-gnu \ ignore-value intprops lstat mktime readlink \ - socklen stdio strftime strtoumax symlink sys_stat + socklen stdarg stdio strftime strtoumax symlink sys_stat GNULIB_TOOL_FLAGS = \ --conditional-dependencies --import --no-changelog --no-vc-files \ --makefile-name=gnulib.mk === modified file 'src/ChangeLog' --- src/ChangeLog 2011-05-04 06:13:23 +0000 +++ src/ChangeLog 2011-05-04 07:20:46 +0000 @@ -1,5 +1,16 @@ 2011-05-04 Paul Eggert + * term.c (vfatal): Remove stray call to va_end. + It's not needed and the C Standard doesn't allow it here anyway. + + Use C99's va_copy to avoid undefined behavior on x86-64 GNU/Linux. + * eval.c (verror): doprnt a copy of ap, not the original. (Bug#8545) + + * eval.c (verror): OK to create a string of up to MOST_POSITIVE_FIXNUM + bytes. + + * term.c: Don't include , as does that. + Arithmetic overflows now return float rather than wrapping around. (Bug#8611). * data.c: Include . === modified file 'src/eval.c' --- src/eval.c 2011-04-30 19:00:39 +0000 +++ src/eval.c 2011-05-04 07:19:21 +0000 @@ -1994,7 +1994,7 @@ { char buf[4000]; size_t size = sizeof buf; - size_t size_max = min (MOST_POSITIVE_FIXNUM, SIZE_MAX); + size_t size_max = min (MOST_POSITIVE_FIXNUM + 1, SIZE_MAX); size_t mlen = strlen (m); char *buffer = buf; size_t used; @@ -2002,7 +2002,10 @@ while (1) { - used = doprnt (buffer, size, m, m + mlen, ap); + va_list ap_copy; + va_copy (ap_copy, ap); + used = doprnt (buffer, size, m, m + mlen, ap_copy); + va_end (ap_copy); /* Note: the -1 below is because `doprnt' returns the number of bytes excluding the terminating null byte, and it always terminates with a === modified file 'src/term.c' --- src/term.c 2011-04-24 09:00:03 +0000 +++ src/term.c 2011-05-04 07:20:46 +0000 @@ -26,7 +26,6 @@ #include #include #include -#include #include #include "lisp.h" @@ -3619,7 +3618,6 @@ vfprintf (stderr, str, ap); if (!(strlen (str) > 0 && str[strlen (str) - 1] == '\n')) fprintf (stderr, "\n"); - va_end (ap); fflush (stderr); exit (1); } From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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: Wed, 04 May 2011 09:53: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: To: Paul Eggert Cc: 8545@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130450273924345 (code B ref 8545); Wed, 04 May 2011 09:53:02 +0000 Received: (at 8545) by debbugs.gnu.org; 4 May 2011 09:52:19 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QHYkk-0006Kc-OL for submit@debbugs.gnu.org; Wed, 04 May 2011 05:52:19 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QHYki-0006KO-AU for 8545@debbugs.gnu.org; Wed, 04 May 2011 05:52:16 -0400 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QHYkc-0008Ip-Tq; Wed, 04 May 2011 05:52:10 -0400 Date: Wed, 04 May 2011 05:52:10 -0400 Message-Id: From: Eli Zaretskii In-reply-to: <4DC10012.8020809@cs.ucla.edu> (message from Paul Eggert on Wed, 04 May 2011 00:28:18 -0700) 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> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > Date: Wed, 04 May 2011 00:28:18 -0700 > From: Paul Eggert > CC: 8545@debbugs.gnu.org > > On 04/29/11 04:16, Eli Zaretskii wrote: > > I guess so, yes. I would like to have other opinions, though, so I > > will start a new thread on emacs-devel about that. > > It seems from that discussion that strings can contain MOST_POSITIVE_FIXNUM bytes. I think the conclusion was that it can contain MOST_POSITIVE_FIXNUM _including_the_terminating_null_. > Also, that va_arg bug really needs fixing. So I plan to install the following > patch after some more testing. This assumes va_copy exists, which may affect > the Windows port, but a one-line macro should suffice if it doesn't have > va_copy already. Right, I will take care of that when this is installed. Thanks. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 May 2011 14:57: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org, Emacs Development Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130452101421541 (code B ref 8545); Wed, 04 May 2011 14:57:02 +0000 Received: (at 8545) by debbugs.gnu.org; 4 May 2011 14:56:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QHdVV-0005bM-D1 for submit@debbugs.gnu.org; Wed, 04 May 2011 10:56:53 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QHdVT-0005b9-Cu for 8545@debbugs.gnu.org; Wed, 04 May 2011 10:56:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id ED3E339E8108; Wed, 4 May 2011 07:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv8K4bRud9SX; Wed, 4 May 2011 07:56:44 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 7C2D239E80FA; Wed, 4 May 2011 07:56:44 -0700 (PDT) Message-ID: <4DC1692B.1090101@cs.ucla.edu> Date: Wed, 04 May 2011 07:56:43 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 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> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 05/04/11 02:52, Eli Zaretskii wrote: >> It seems from that discussion that strings can contain MOST_POSITIVE_FIXNUM bytes. > I think the conclusion was that it can contain MOST_POSITIVE_FIXNUM > _including_the_terminating_null_. Hmm, that's not how I read . I understood the argument to be that a buffer must contain at most MOST_POSITIVE_FIXNUM - 1 bytes due to other reasons, but it's OK to have "a string whose length is MOST_POSITIVE_FIXNUM", i.e., (= (length STRING) most-positive-fixnum), because we already check buffer sizes before inserting strings. If you count the trailing byte, the length of the underlying C character array would be MOST_POSITIVE_FIXNUM + 1. I'll CC: this to emacs-devel just in case I misinterpreted that. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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, 05 May 2011 20:37: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: To: Paul Eggert , Stefan Monnier Cc: 8545@debbugs.gnu.org, emacs-devel@gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130462781919846 (code B ref 8545); Thu, 05 May 2011 20:37:02 +0000 Received: (at 8545) by debbugs.gnu.org; 5 May 2011 20:36:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QI5IA-0005A3-Mh for submit@debbugs.gnu.org; Thu, 05 May 2011 16:36:58 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QI5I7-00059q-VQ for 8545@debbugs.gnu.org; Thu, 05 May 2011 16:36:57 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LKQ00D00P8XTX00@a-mtaout22.012.net.il> for 8545@debbugs.gnu.org; Thu, 05 May 2011 23:36:50 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.234.175]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKQ00DTCP9BH540@a-mtaout22.012.net.il>; Thu, 05 May 2011 23:36:50 +0300 (IDT) Date: Thu, 05 May 2011 23:36:49 +0300 From: Eli Zaretskii In-reply-to: <4DC1692B.1090101@cs.ucla.edu> X-012-Sender: halo1@inter.net.il Message-id: <83ei4cnau6.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> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> <4DC1692B.1090101@cs.ucla.edu> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Wed, 04 May 2011 07:56:43 -0700 > From: Paul Eggert > CC: 8545@debbugs.gnu.org, Emacs Development > > On 05/04/11 02:52, Eli Zaretskii wrote: > >> It seems from that discussion that strings can contain MOST_POSITIVE_FIXNUM bytes. > > I think the conclusion was that it can contain MOST_POSITIVE_FIXNUM > > _including_the_terminating_null_. > > Hmm, that's not how I read > . > > I understood the argument to be that a buffer must contain at most > MOST_POSITIVE_FIXNUM - 1 bytes due to other reasons, but it's OK > to have "a string whose length is MOST_POSITIVE_FIXNUM", i.e., > (= (length STRING) most-positive-fixnum), because we already check > buffer sizes before inserting strings. If you > count the trailing byte, the length of the underlying C character > array would be MOST_POSITIVE_FIXNUM + 1. Stefan, could you please chime in? From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: Merged fixes for 8600, 8601, 8602, and (partially) for 8545 References: <4DB50AB9.6060100@cs.ucla.edu> In-Reply-To: <4DB50AB9.6060100@cs.ucla.edu> Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 May 2011 07:31: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: To: 8545@debbugs.gnu.org, 8600-done@debbugs.gnu.org, 8601-done@debbugs.gnu.org, 8602-done@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130466700811628 (code B ref 8545); Fri, 06 May 2011 07:31:01 +0000 Received: (at 8545) by debbugs.gnu.org; 6 May 2011 07:30:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIFUE-00031P-AV for submit@debbugs.gnu.org; Fri, 06 May 2011 03:30:06 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIFUC-00030V-8W; Fri, 06 May 2011 03:30:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id AA3A539E8118; Fri, 6 May 2011 00:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nku4im7TOEsc; Fri, 6 May 2011 00:29:57 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 2BCF039E8113; Fri, 6 May 2011 00:29:57 -0700 (PDT) Message-ID: <4DC3A374.1090401@cs.ucla.edu> Date: Fri, 06 May 2011 00:29:56 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) I committed to the Emacs trunk a merge (bzr 104134) that has fixes for the following bugs: * Bug#8600 - The fix removes the garbage element of code_space. * Bug#8601 - Here I assumed that the "* 2" is a typo. * Bug#8602 - This fixes some large-int-to-float screwups in the Lisp reader. * Bug#8545 - This fixes the bug where the code should have called va_copy, but didn't. Also, I changed a limit so that the MOST_POSITIVE_FIXNUM limit for strings applies to their length, i.e., does not include the null termination byte. Stefan hasn't had time to chime in, but if this last change turns out to be incorrect I will back it out. This merge doesn't entirely fix Bug#8545, so I'll leave that bug open; the others I'll close. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 May 2011 13:34: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org, Paul Eggert , emacs-devel@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130468881414241 (code B ref 8545); Fri, 06 May 2011 13:34:01 +0000 Received: (at 8545) by debbugs.gnu.org; 6 May 2011 13:33:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIL9y-0003he-EA for submit@debbugs.gnu.org; Fri, 06 May 2011 09:33:34 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIL9v-0003hN-0v for 8545@debbugs.gnu.org; Fri, 06 May 2011 09:33:32 -0400 Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:40224 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QIL9o-0005ql-OI; Fri, 06 May 2011 09:33:24 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 1D9F866168; Fri, 6 May 2011 10:33:21 -0300 (ART) From: Stefan Monnier 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> <4DB9146D.2040702@cs.ucla.edu> <4DB9E5FF.9020506@cs.ucla.edu> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> <4DC1692B.1090101@cs.ucla.edu> <83ei4cnau6.fsf@gnu.org> Date: Fri, 06 May 2011 10:33:21 -0300 In-Reply-To: <83ei4cnau6.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 May 2011 23:36:49 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.0 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.0 (------) >> >> It seems from that discussion that strings can contain >> >> MOST_POSITIVE_FIXNUM bytes. >> > I think the conclusion was that it can contain MOST_POSITIVE_FIXNUM >> > _including_the_terminating_null_. >> >> Hmm, that's not how I read >> . >> >> I understood the argument to be that a buffer must contain at most >> MOST_POSITIVE_FIXNUM - 1 bytes due to other reasons, but it's OK >> to have "a string whose length is MOST_POSITIVE_FIXNUM", i.e., >> (= (length STRING) most-positive-fixnum), because we already check >> buffer sizes before inserting strings. If you >> count the trailing byte, the length of the underlying C character >> array would be MOST_POSITIVE_FIXNUM + 1. > Stefan, could you please chime in? I'm not sure I understand the details more than you do. AFAIK the MOST_POSITIVE_FIXNUM limit only comes into play when the number goes through Lisp_Object somewhere. And we never show "length, including terminating nul-byte" to Elisp, so the nul-byte shouldn't matter: while the C array will have size MOST_POSITIVE_FIXNUM + 1, this will only be represented in EMACS_INT which can accommodate it just fine. Stefan From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 May 2011 14:42: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: To: Stefan Monnier Cc: Eli Zaretskii , 8545@debbugs.gnu.org, emacs-devel@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130469291120858 (code B ref 8545); Fri, 06 May 2011 14:42:01 +0000 Received: (at 8545) by debbugs.gnu.org; 6 May 2011 14:41:51 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIME3-0005QM-CD for submit@debbugs.gnu.org; Fri, 06 May 2011 10:41:51 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIME1-0005QB-KT for 8545@debbugs.gnu.org; Fri, 06 May 2011 10:41:49 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 27EA839E8113; Fri, 6 May 2011 07:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKgLHwn3WpYK; Fri, 6 May 2011 07:41:42 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id C73ED39E810D; Fri, 6 May 2011 07:41:42 -0700 (PDT) Message-ID: <4DC408A6.4080406@cs.ucla.edu> Date: Fri, 06 May 2011 07:41:42 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 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> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> <4DC1692B.1090101@cs.ucla.edu> <83ei4cnau6.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 05/06/11 06:33, Stefan Monnier wrote: > I'm not sure I understand the details more than you do. AFAIK the > MOST_POSITIVE_FIXNUM limit only comes into play when the number goes > through Lisp_Object somewhere. And we never show "length, including > terminating nul-byte" to Elisp, so the nul-byte shouldn't matter: while > the C array will have size MOST_POSITIVE_FIXNUM + 1, this will only be > represented in EMACS_INT which can accommodate it just fine. First, you say you're not sure you understand the details; then, you explain the situation perfectly! :-) Thanks. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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, 06 May 2011 15:05: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: To: Stefan Monnier Cc: 8545@debbugs.gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130469429223045 (code B ref 8545); Fri, 06 May 2011 15:05:01 +0000 Received: (at 8545) by debbugs.gnu.org; 6 May 2011 15:04:52 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIMaJ-0005zd-O0 for submit@debbugs.gnu.org; Fri, 06 May 2011 11:04:51 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIMaF-0005zL-GM for 8545@debbugs.gnu.org; Fri, 06 May 2011 11:04:49 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LKS001004G4J900@a-mtaout22.012.net.il> for 8545@debbugs.gnu.org; Fri, 06 May 2011 18:03:47 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.234.175]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKS000FH4I8DAI0@a-mtaout22.012.net.il>; Fri, 06 May 2011 18:03:45 +0300 (IDT) Date: Fri, 06 May 2011 18:03:46 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83vcxnlvl9.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> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> <4DC1692B.1090101@cs.ucla.edu> <83ei4cnau6.fsf@gnu.org> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > From: Stefan Monnier > Cc: Paul Eggert , 8545@debbugs.gnu.org, emacs-devel@gnu.org > Date: Fri, 06 May 2011 10:33:21 -0300 > > And we never show "length, including > terminating nul-byte" to Elisp, so the nul-byte shouldn't matter If you are sure of that, then I agree it's fine to use MOST_POSITIVE_FIXNUM+1. I wasn't sure. I do see in C variables that explicitly use the string position of the null byte; I was afraid that they could somehow leak to Lisp. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 May 2011 17:14: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.13047019982406 (code B ref 8545); Fri, 06 May 2011 17:14:01 +0000 Received: (at 8545) by debbugs.gnu.org; 6 May 2011 17:13:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIOac-0000cl-Fi for submit@debbugs.gnu.org; Fri, 06 May 2011 13:13:18 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIOaa-0000cY-T2 for 8545@debbugs.gnu.org; Fri, 06 May 2011 13:13:17 -0400 Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:46305 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QIOaU-0004Up-K8; Fri, 06 May 2011 13:13:11 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 72F4B66248; Fri, 6 May 2011 14:13:06 -0300 (ART) From: Stefan Monnier 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> <4DB9146D.2040702@cs.ucla.edu> <4DB9E5FF.9020506@cs.ucla.edu> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> <4DC1692B.1090101@cs.ucla.edu> <83ei4cnau6.fsf@gnu.org> <83vcxnlvl9.fsf@gnu.org> Date: Fri, 06 May 2011 14:13:06 -0300 In-Reply-To: <83vcxnlvl9.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 06 May 2011 18:03:46 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.0 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.0 (------) >> And we never show "length, including >> terminating nul-byte" to Elisp, so the nul-byte shouldn't matter > If you are sure of that, then I agree it's fine to use > MOST_POSITIVE_FIXNUM+1. I wasn't sure. I do see in C variables that > explicitly use the string position of the null byte; I was afraid that > they could somehow leak to Lisp. I don't know enough to guarantee you that they can never leak to Lisp, but I can't think of any reason why they should. And note that "the position of the nul byte" is the same as "the length of the list", so it's still <= MOST_POSITIVE_FIXNUM. It's only the position after the nul byte that would overflow. Stefan From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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, 06 May 2011 19:58: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: To: Stefan Monnier Cc: 8545@debbugs.gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130471186017000 (code B ref 8545); Fri, 06 May 2011 19:58:02 +0000 Received: (at 8545) by debbugs.gnu.org; 6 May 2011 19:57:40 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIR9f-0004Q9-RX for submit@debbugs.gnu.org; Fri, 06 May 2011 15:57:40 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIR9d-0004Pt-HT for 8545@debbugs.gnu.org; Fri, 06 May 2011 15:57:38 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LKS00500HTVF100@a-mtaout20.012.net.il> for 8545@debbugs.gnu.org; Fri, 06 May 2011 22:57:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.234.175]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKS004ELI3R1AP0@a-mtaout20.012.net.il>; Fri, 06 May 2011 22:57:31 +0300 (IDT) Date: Fri, 06 May 2011 22:57:30 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83k4e3lhzp.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> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> <4DC1692B.1090101@cs.ucla.edu> <83ei4cnau6.fsf@gnu.org> <83vcxnlvl9.fsf@gnu.org> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > From: Stefan Monnier > Cc: eggert@cs.ucla.edu, 8545@debbugs.gnu.org, emacs-devel@gnu.org > Date: Fri, 06 May 2011 14:13:06 -0300 > > note that "the position of the nul byte" is the same as "the length > of the list", so it's still <= MOST_POSITIVE_FIXNUM. It's only the > position after the nul byte that would overflow. But what about this code and its commentary (from next_element_from_c_string): /* IT's position can be greater IT->string_nchars in case a field width or precision has been specified when the iterator was initialized. */ if (IT_CHARPOS (*it) >= it->end_charpos) { /* End of the game. */ ... This happens when the iterator is initialized by reseat_to_string. Admittedly, it's not very practical to have such huge strings that are padded to an even larger width... From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 May 2011 03:19: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: To: Eli Zaretskii Cc: 8545@debbugs.gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130473833825437 (code B ref 8545); Sat, 07 May 2011 03:19:02 +0000 Received: (at 8545) by debbugs.gnu.org; 7 May 2011 03:18:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIY2j-0006cD-NP for submit@debbugs.gnu.org; Fri, 06 May 2011 23:18:58 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIY2i-0006bw-8I for 8545@debbugs.gnu.org; Fri, 06 May 2011 23:18:56 -0400 Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:51180 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QIY2c-0005jX-HM; Fri, 06 May 2011 23:18:50 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 5CAEF66248; Sat, 7 May 2011 00:18:47 -0300 (ART) From: Stefan Monnier 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> <4DB9146D.2040702@cs.ucla.edu> <4DB9E5FF.9020506@cs.ucla.edu> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> <4DC1692B.1090101@cs.ucla.edu> <83ei4cnau6.fsf@gnu.org> <83vcxnlvl9.fsf@gnu.org> <83k4e3lhzp.fsf@gnu.org> Date: Sat, 07 May 2011 00:18:47 -0300 In-Reply-To: <83k4e3lhzp.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 06 May 2011 22:57:30 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.0 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.0 (------) >> note that "the position of the nul byte" is the same as "the length >> of the list", so it's still <= MOST_POSITIVE_FIXNUM. It's only the >> position after the nul byte that would overflow. > But what about this code and its commentary (from > next_element_from_c_string): > /* IT's position can be greater IT->string_nchars in case a field > width or precision has been specified when the iterator was > initialized. */ > if (IT_CHARPOS (*it) >= it->end_charpos) > { > /* End of the game. */ > ... Do these ever make it into a Lisp_Object? Stefan From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: issues with recent doprnt-related changes 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: Sat, 07 May 2011 07:57: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: To: Stefan Monnier Cc: 8545@debbugs.gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org Reply-To: Eli Zaretskii Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130475501716393 (code B ref 8545); Sat, 07 May 2011 07:57:02 +0000 Received: (at 8545) by debbugs.gnu.org; 7 May 2011 07:56:57 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIcNk-0004GL-FB for submit@debbugs.gnu.org; Sat, 07 May 2011 03:56:56 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIcNh-0004G8-M4 for 8545@debbugs.gnu.org; Sat, 07 May 2011 03:56:54 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LKT00B00FD85Z00@a-mtaout20.012.net.il> for 8545@debbugs.gnu.org; Sat, 07 May 2011 10:55:58 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.234.175]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKT00AD2FD1KMD0@a-mtaout20.012.net.il>; Sat, 07 May 2011 10:55:50 +0300 (IDT) Date: Sat, 07 May 2011 10:55:52 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <838vujkkqf.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> <83d3k571ee.fsf@gnu.org> <4DC10012.8020809@cs.ucla.edu> <4DC1692B.1090101@cs.ucla.edu> <83ei4cnau6.fsf@gnu.org> <83vcxnlvl9.fsf@gnu.org> <83k4e3lhzp.fsf@gnu.org> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > From: Stefan Monnier > Cc: eggert@cs.ucla.edu, 8545@debbugs.gnu.org, emacs-devel@gnu.org > Date: Sat, 07 May 2011 00:18:47 -0300 > > >> note that "the position of the nul byte" is the same as "the length > >> of the list", so it's still <= MOST_POSITIVE_FIXNUM. It's only the > >> position after the nul byte that would overflow. > > > But what about this code and its commentary (from > > next_element_from_c_string): > > > /* IT's position can be greater IT->string_nchars in case a field > > width or precision has been specified when the iterator was > > initialized. */ > > if (IT_CHARPOS (*it) >= it->end_charpos) > > { > > /* End of the game. */ > > ... > > Do these ever make it into a Lisp_Object? Well, the resulting string can be returned by format-mode-line, for example. From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: Merged fixes for 8600, 8601, 8602, and (partially) for 8545 Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2020 12:38: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: To: Paul Eggert Cc: 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.160008707830966 (code B ref 8545); Mon, 14 Sep 2020 12:38:01 +0000 Received: (at 8545) by debbugs.gnu.org; 14 Sep 2020 12:37:58 +0000 Received: from localhost ([127.0.0.1]:52993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kHnk6-00083O-CF for submit@debbugs.gnu.org; Mon, 14 Sep 2020 08:37:58 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kHnk3-000835-MH for 8545@debbugs.gnu.org; Mon, 14 Sep 2020 08:37:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=PVjVwwjoezbMbDjBU5axBLyxgozuft3RQwNw63TWRQ4=; b=rfdsF7yYwZSpQKKfvWceuyiP1+ 7p/RHlH2f1Jil9DILg+I0HHpKT8I3+MFmAW0y8C0Aajg/rg8yLJ8Qzcap8ERg9vusqksOR6lZmpBy xEcR6wMsZZuK59Q6Hb7UacOFHhYyqQBWDxU0ck1i7V2PzvG3tCPzctJ/lgjiQ6D1oP4k=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kHnjt-0001TJ-A5; Mon, 14 Sep 2020 14:37:48 +0200 From: Lars Ingebrigtsen References: <4DB50AB9.6060100@cs.ucla.edu> <4DC3A374.1090401@cs.ucla.edu> X-Now-Playing: Cosey Fanni Tutti's _Tutti_: "Split" Date: Mon, 14 Sep 2020 14:37:44 +0200 In-Reply-To: <4DC3A374.1090401@cs.ucla.edu> (Paul Eggert's message of "Fri, 06 May 2011 00:29:56 -0700") Message-ID: <87d02obkkn.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Paul Eggert writes: > * Bug#8545 - This fixes the bug where the code should have called > va_copy, but didn't. Also, I changed a limit so that > the MOST_POSITIVE_FIXNUM limit for strings applies to > their length, i.e., [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Paul Eggert writes: > * Bug#8545 - This fixes the bug where the code should have called > va_copy, but didn't. Also, I changed a limit so that > the MOST_POSITIVE_FIXNUM limit for strings applies to > their length, i.e., does not include the null termination > byte. Stefan hasn't had time to chime in, but if this > last change turns out to be incorrect I will back it out. > > This merge doesn't entirely fix Bug#8545, so I'll leave that bug open; > the others I'll close. This was a quite long thread, and had a bunch of related bugs discussed. Skimming this thread, I'm not sure exactly what the remaining problem in this bug report is -- the discussion kinda petered out... This is nine years old -- is there anything more to be done here? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sat Jun 21 10:39:04 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Paul Eggert Subject: bug#8545: closed (Re: bug#8545: Merged fixes for 8600, 8601, 8602, and (partially) for 8545) Message-ID: References: <83bli89p57.fsf@gnu.org> <4DB50AB9.6060100@cs.ucla.edu> X-Gnu-PR-Message: they-closed 8545 X-Gnu-PR-Package: emacs Reply-To: 8545@debbugs.gnu.org Date: Mon, 14 Sep 2020 18:42:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1600108922-15030-1" This is a multi-part message in MIME format... ------------=_1600108922-15030-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #8545: issues with recent doprnt-related changes which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 8545@debbugs.gnu.org. --=20 8545: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D8545 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1600108922-15030-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 8545-done) by debbugs.gnu.org; 14 Sep 2020 18:42:00 +0000 Received: from localhost ([127.0.0.1]:56216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kHtQO-0003uD-B4 for submit@debbugs.gnu.org; Mon, 14 Sep 2020 14:42:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kHtQM-0003ty-PY for 8545-done@debbugs.gnu.org; Mon, 14 Sep 2020 14:41:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58010) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kHtQG-0008Ek-Px; Mon, 14 Sep 2020 14:41:52 -0400 Received: from [176.228.60.248] (port=4048 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kHtQG-0001RW-5r; Mon, 14 Sep 2020 14:41:52 -0400 Date: Mon, 14 Sep 2020 21:41:56 +0300 Message-Id: <83bli89p57.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87d02obkkn.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 14 Sep 2020 14:37:44 +0200) Subject: Re: bug#8545: Merged fixes for 8600, 8601, 8602, and (partially) for 8545 References: <4DB50AB9.6060100@cs.ucla.edu> <4DC3A374.1090401@cs.ucla.edu> <87d02obkkn.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 8545-done Cc: eggert@cs.ucla.edu, 8545-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Mon, 14 Sep 2020 14:37:44 +0200 > Cc: 8545@debbugs.gnu.org > > This was a quite long thread, and had a bunch of related bugs discussed. > Skimming this thread, I'm not sure exactly what the remaining problem in > this bug report is -- the discussion kinda petered out... > > This is nine years old -- is there anything more to be done here? I don't think so, so I'm closing this bug. ------------=_1600108922-15030-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 25 Apr 2011 05:47:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEEdR-0004PJ-QA for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:47:02 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QEEdP-0004Op-SU for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:47:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEEdJ-0000yv-RZ for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:46:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:42980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEEdJ-0000yq-Q4 for submit@debbugs.gnu.org; Mon, 25 Apr 2011 01:46:53 -0400 Received: from eggs.gnu.org ([140.186.70.92]:34848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEEdI-0003LV-Ua for bug-gnu-emacs@gnu.org; Mon, 25 Apr 2011 01:46:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEEdH-0000yZ-Oi for bug-gnu-emacs@gnu.org; Mon, 25 Apr 2011 01:46:52 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:57012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEEdH-0000xq-Fb; Mon, 25 Apr 2011 01:46:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id A617B39E80E0; Sun, 24 Apr 2011 22:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHaWohnIK7vt; Sun, 24 Apr 2011 22:46:42 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 19A6639E8082; Sun, 24 Apr 2011 22:46:42 -0700 (PDT) Message-ID: <4DB50AB9.6060100@cs.ucla.edu> Date: Sun, 24 Apr 2011 22:46:33 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: issues with recent doprnt-related changes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.7 (----) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.7 (----) This is a followup to Bug#8435. Eli invited me to review the recent doprnt-related changes, so here's a quick review: * doprnt returns size_t. But Stefan wrote that he prefers sizes to be signed values, and doprnt always returns a value that can fit in EMACS_INT. So shouldn't doprnt return EMACS_INT, as it did before? * doprnt supports only a small subset of the standard printf formats, but this subset is not documented. It's unclear what the subset is. Or it's a superset of the subset, with %S and %l? Anyway, this should be documented clearly in the lead comment. * I suggest that every feature in doprnt be a feature that is actually needed and used; this will simplify maintainance. * Format strings never include embedded null bytes, so there's no need for doprnt to support that. * If the format string is too long, the alloca inside doprnt will crash Emacs on some hosts. I suggest removing the alloca, instituting a fixed size limit on format specifiers, and documenting that limit. Since user code cannot ever supply one of these formats, that should be good enough. * The width features of doprnt (e.g., %25s) are never used. That part of the code is still buggy; please see some comments below. I suggest removing it entirely; this will simplify things. But if not: - doprnt mishandles format specifications such as %0.0.0d. It passes them off to printf, and this results in undefined behavior, near as I can tell. - doprnt uses atoi (&fmtcpy[1]), but surely this isn't right if there are flags such as '-'. - Quite possibly there are other problems in this area, but I didn't want to spend further time reviewing a never-used feature. * In this code, in verror: used = doprnt (buffer, size, m, m + mlen, ap); /* Note: the -1 below is because `doprnt' returns the number of bytes excluding the terminating null byte, and it always terminates with a null byte, even when producing a truncated message. */ if (used < size - 1) break; I don't see the reason for the "- 1". If you replace this with: used = doprnt (buffer, size, m, m + mlen, ap); if (used < size) break; the code should still work, because, when used < size, the buffer should be properly null-terminated. If it isn't then there's something wrong with doprnt, no? * In this code, in verror: else if (size < size_max - 1) size = size_max - 1; there's no need for the "- 1"s. Just use this: else if (size < size_max) size = size_max; * This code in verror: if (buffer == buf) buffer = (char *) xmalloc (size); else buffer = (char *) xrealloc (buffer, size); uses xrealloc, which is unnecessarily expensive, as it may copy the buffer's contents even though they are entirely garbage here. Use this instead, to avoid the useless copy: if (buffer != buf) xfree (buffer); buffer = (char *) xmalloc (size); ------------=_1600108922-15030-1-- From unknown Sat Jun 21 10:39:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8545: Merged fixes for 8600, 8601, 8602, and (partially) for 8545 Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Sep 2020 02:02: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: To: Lars Ingebrigtsen Cc: 8545@debbugs.gnu.org Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.160022170916122 (code B ref 8545); Wed, 16 Sep 2020 02:02:01 +0000 Received: (at 8545) by debbugs.gnu.org; 16 Sep 2020 02:01:49 +0000 Received: from localhost ([127.0.0.1]:32793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIMlZ-0004By-BO for submit@debbugs.gnu.org; Tue, 15 Sep 2020 22:01:49 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49354) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIMlW-0004Bj-G9 for 8545@debbugs.gnu.org; Tue, 15 Sep 2020 22:01:47 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 311351600DE; Tue, 15 Sep 2020 19:01:40 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id MhvMe9R7VrkV; Tue, 15 Sep 2020 19:01:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 811A61600F1; Tue, 15 Sep 2020 19:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HapeVAD2aHlF; Tue, 15 Sep 2020 19:01:39 -0700 (PDT) Received: from [192.168.1.9] (cpe-75-82-69-226.socal.res.rr.com [75.82.69.226]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5C0C21600DE; Tue, 15 Sep 2020 19:01:39 -0700 (PDT) References: <4DB50AB9.6060100@cs.ucla.edu> <4DC3A374.1090401@cs.ucla.edu> <87d02obkkn.fsf@gnus.org> <83bli89p57.fsf@gnu.org> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDVlFRVEFRZ0FQ d0liQXdZTApDUWdIQXdJR0ZRZ0NDUW9MQkJZQ0F3RUNIZ0VDRjRBV0lRUitONUtwMkt6MzFq TzhGWWp0bCtrT1lxcCtOQVVDClh5Vzlsd1VKRks0THN3QUtDUkR0bCtrT1lxcCtOS05WRC85 SE1zSTE2MDZuMFV1VFhId0lUc3lPakFJOVNET1QKK0MzRFV2NnFsTTVCSDJuV0FNVGlJaXlB NXVnbHNKdjkzb2kydk50RmYvUS9tLzFjblpXZ25WbkV4a3lMSTRFTgpTZDF1QnZyMC9sQ1Nk UGxQME1nNkdXU3BYTXUreDB2ZFQwQWFaTk9URTBGblB1b2xkYzNYRDc2QzJxZzhzWC9pCmF4 WFRLSHk5UCtCbEFxL0NzNy9weERRMEV6U24wVVNaMkMwbDV2djRQTXBBL3BpY25TNks2MDlK dkRHYU9SbXcKWmVYSVpxUU5aVitaUXMrVVl0Vm9ndURUcWJ5M0lVWTFJOEJsWEhScHRhajlB TW40VW9oL0NxcFFsVm9qb3lXbApIcWFGbm5KQktlRjBodko5U0F5YWx3dXpBakc3dlFXMDdN WW5jYU9GbTB3b2lLYmc1SkxPOEY0U0JUSWt1TzBECkNmOW5MQWF5NlZzQjRyendkRWZSd2pQ TFlBbjdNUjNmdkhDRXpmcmtsZFRyYWlCTzFUMGllREs4MEk3c0xmNnAKTWVDWUkxOXBVbHgw L05STUdDZGRpRklRZGZ0aEtXWEdSUzVMQXM4andCZjhINkc1UFdpblByRUlhb21JUDIxaQp2 dWhRRDA3YllxOUlpSWRlbGpqVWRIY0dJMGkvQjRNNTZaYWE4RmYzOGluaU9sckRZQ21ZV1I0 ZENXWml1UWVaCjNPZ3FlUXM5YTZqVHZnZERHVm1SVnFZK2p6azhQbGFIZmNvazhST2hGY0hL a2NmaHVCaEwyNWhsUklzaFJET0UKc2tYcUt3bnpyYnFnYTNHWFpYZnNYQW9GYnpOaExkTHY5 QStMSkFZU2tYUDYvNXFkVHBFTFZHb3N5SDg4NFZkYgpCcGtHSTA0b1lWcXVsYmtDRFFSTWdI SmtBUkFBcG9YcnZ4UDNESWZqQ05PdFhVL1Bkd01TaEtkWC9SbFNzNVBmCnVuVjF3YktQOGhl clhIcnZRZEZWcUVDYVRTeG1saHpiazhYMFBrWTlnY1ZhVTJPNDlUM3FzT2QxY0hlRjUyWUYK R0V0MExoc0JlTWpnTlg1dVoxVjc2cjhneWVWbEZwV1diMFNJd0pVQkhyRFhleEY2N3VwZVJi MnZkSEJqWUROZQp5U24rMEI3Z0ZFcXZWbVp1K0xhZHVkRHA2a1FMamF0RnZIUUhVU0dOc2hC bmtrY2FUYmlJOVBzdDBHQ2MyYWl6Cm5CaVBQQTJXUXhBUGxQUmgzT0dUc241VEhBRG1ianFZ NkZFTUxhc1ZYOERTQ2JsTXZMd05lTy84U3h6aUJpZGgKcUxwSkNxZFFSV0hrdTVYeGdJa0dl S096NU9MRHZYSFdKeWFmckVZamprUzZBazZCNXo2c3ZLbGlDbFduakhRYwpqbFB6eW9GRmdL VEVmY3FEeENqNFJZMEQwRGd0RkQwTmZ5ZU9pZHJTQi9TelRlMmh3cnlRRTNycFNpcW8rMGNH CmR6aDR5QUhLWUorVXJYWjRwOTNaaGpHZktEMXhsck5ZRGxXeVc5UEdtYnZxRnVEbWlJQVFm OVdEL3d6RWZJQ2MKK0YrdURESSt1WWtSeFVGcDkyeWttZGhERUZnMXlqWXNVOGlHVTY5YUh5 dmhxMzZ6NHpjdHZicWhSTnpPV0IxYgpWSi9kSU1EdnNFeEdjWFFWRElUN3NETlh2MHdFM2pL U0twcDdOREcxb1hVWEwrMitTRjk5S2p5NzUzQWJRU0FtCkg2MTdmeUJOd2hKV3ZRWWcrbVV2 UHBpR090c2VzOUVYVUkzbFM0djBNRWFQRzQzZmxFczFVUisxcnBGUVdWSG8KMXkxT08rc0FF UUVBQVlrQ1BBUVlBUWdBSmdJYkRCWWhCSDQza3FuWXJQZldNN3dWaU8yWDZRNWlxbjQwQlFK ZgpKYjJ6QlFrVXJndlBBQW9KRU8yWDZRNWlxbjQwY25NUC8xN0NnVWtYVDlhSUpyaVBNOHdi Y2VZcmNsNytiZFlFCmY3OVNsd1NiYkhON1I0Q29JSkZPbE45Uy8zNHR5cEdWWXZwZ21DSkRZ RlRCeHlQTzkyaU1YRGdBNCtjV0h6dDUKVDFhWU85aHNLaGg3dkR0Sys2UHJvWkdjKzA4Z1VU WEhoYjk3aE1NUWhrbkpsbmZqcFNFQzllbTkwNkZVK0k5MwpUMWZUR3VwbkJhM2FXY0s4ak0w SmFCR2J5MmhHMVMzb2xhRExTVHRCSU5OQlltdnVXUjlNS09oaHFEcmxrNWN3CkZESkxoNU5y WHRlRVkwOFdBemNMekczcGtyWFBIa0ZlTVF0ZnFrMGpMZEdHdkdDM05DSWtxWXJkTGhpUnZH cHIKdTM4QzI2UkVuNWY0STB2R0UzVmZJWEhlOFRNQ05tUXV0MU50TXVVbXBESXkxYUx4R3p1 cHRVaG5PSk4vL3IrVgpqRFBvaTNMT3lTTllwaHFlL2RNdWJzZlVyNm9oUDQxbUtGODFGdXdJ NGFtcUp0cnFJTDJ5cWF4M2EwcWxmd0N4ClhmdGllcUpjdWVrWCtlQ1BEQ0tyWU1YUjBGWWd3 cEcySVRaVUd0ckVqRVNsRTZEc2N4NzM0SEtkcjVPUklvY0wKVVVLRU9HZWlVNkRHaEdGZGI1 VHd1MFNuK3UxbVVQRE4wTSsrQ2RNdkNsSUU4a2xvNEc5MUVPSW11MVVwYjh4YwpPUFF3eGgx andxU3JVNVF3b05tU1llZ1FTSExwSVV1ckZ6MWlRVWgxdnBQWHpLaW5rV0VxdjRJcUExY2lM K0x5CnlTdUxrcDdNc0pwVlJNYldKQ05XT09TYmFING9EQko1ZEhNR2MzNXg1bW9zQ2s5MFBY a251RkREc1lIZkRvNXMKbWY5bG82WVh4N045Cj0zTGFJCi0tLS0tRU5EIFBHUCBQVUJMSUMg S0VZIEJMT0NLLS0tLS0K Organization: UCLA Computer Science Department Message-ID: <7b584d90-dc7f-632c-8b26-73b0e9740bae@cs.ucla.edu> Date: Tue, 15 Sep 2020 19:01:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <83bli89p57.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Several issues from Bug#8545 still remain but its commentary had gotten so long (and our collective memory so hazy :-) that they were hard to see, so I started a new bug report (Bug#43439) with a proposed patch that I hope clarifies and addresses most of the issues.