GNU bug report logs - #8545
issues with recent doprnt-related changes

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Paul Eggert <eggert@HIDDEN>; dated Mon, 25 Apr 2011 05:48:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 7 May 2011 07:56:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 07 03:56:56 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QIcNk-0004GL-FB
	for submit <at> 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 <eliz@HIDDEN>) id 1QIcNh-0004G8-M4
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Sat, 07 May 2011 10:55:50 +0300 (IDT)
Date: Sat, 07 May 2011 10:55:52 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
In-reply-to: <jwvr58byz9s.fsf-monnier+emacs@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Message-id: <838vujkkqf.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DC10012.8020809@HIDDEN>
	<E1QHYkc-0008Ip-Tq@HIDDEN>
	<4DC1692B.1090101@HIDDEN> <83ei4cnau6.fsf@HIDDEN>
	<jwvsjss2bz3.fsf-monnier+emacs@HIDDEN> <83vcxnlvl9.fsf@HIDDEN>
	<jwv8vuj21q0.fsf-monnier+emacs@HIDDEN> <83k4e3lhzp.fsf@HIDDEN>
	<jwvr58byz9s.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, eggert@HIDDEN, emacs-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.1 (--)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: eggert@HIDDEN,  8545 <at> debbugs.gnu.org,  emacs-devel@HIDDEN
> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 7 May 2011 03:18:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 06 23:18:58 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QIY2j-0006cD-NP
	for submit <at> 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 <monnier@HIDDEN>) id 1QIY2i-0006bw-8I
	for 8545 <at> 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 <monnier@HIDDEN>)
	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 <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
Message-ID: <jwvr58byz9s.fsf-monnier+emacs@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN> <E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN> <E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DC10012.8020809@HIDDEN> <E1QHYkc-0008Ip-Tq@HIDDEN>
	<4DC1692B.1090101@HIDDEN> <83ei4cnau6.fsf@HIDDEN>
	<jwvsjss2bz3.fsf-monnier+emacs@HIDDEN> <83vcxnlvl9.fsf@HIDDEN>
	<jwv8vuj21q0.fsf-monnier+emacs@HIDDEN> <83k4e3lhzp.fsf@HIDDEN>
Date: Sat, 07 May 2011 00:18:47 -0300
In-Reply-To: <83k4e3lhzp.fsf@HIDDEN> (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-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, eggert@HIDDEN, emacs-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 6 May 2011 19:57:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 06 15:57:40 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QIR9f-0004Q9-RX
	for submit <at> 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 <eliz@HIDDEN>) id 1QIR9d-0004Pt-HT
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Fri, 06 May 2011 22:57:31 +0300 (IDT)
Date: Fri, 06 May 2011 22:57:30 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
In-reply-to: <jwv8vuj21q0.fsf-monnier+emacs@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Message-id: <83k4e3lhzp.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DC10012.8020809@HIDDEN>
	<E1QHYkc-0008Ip-Tq@HIDDEN>
	<4DC1692B.1090101@HIDDEN> <83ei4cnau6.fsf@HIDDEN>
	<jwvsjss2bz3.fsf-monnier+emacs@HIDDEN> <83vcxnlvl9.fsf@HIDDEN>
	<jwv8vuj21q0.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, eggert@HIDDEN, emacs-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.1 (--)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: eggert@HIDDEN,  8545 <at> debbugs.gnu.org,  emacs-devel@HIDDEN
> 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...




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 6 May 2011 17:13:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 06 13:13:18 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QIOac-0000cl-Fi
	for submit <at> 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 <monnier@HIDDEN>) id 1QIOaa-0000cY-T2
	for 8545 <at> 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 <monnier@HIDDEN>)
	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 <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
Message-ID: <jwv8vuj21q0.fsf-monnier+emacs@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN> <E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN> <E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DC10012.8020809@HIDDEN> <E1QHYkc-0008Ip-Tq@HIDDEN>
	<4DC1692B.1090101@HIDDEN> <83ei4cnau6.fsf@HIDDEN>
	<jwvsjss2bz3.fsf-monnier+emacs@HIDDEN> <83vcxnlvl9.fsf@HIDDEN>
Date: Fri, 06 May 2011 14:13:06 -0300
In-Reply-To: <83vcxnlvl9.fsf@HIDDEN> (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-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, eggert@HIDDEN, emacs-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 6 May 2011 15:04:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 06 11:04:52 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QIMaJ-0005zd-O0
	for submit <at> 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 <eliz@HIDDEN>) id 1QIMaF-0005zL-GM
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Fri, 06 May 2011 18:03:45 +0300 (IDT)
Date: Fri, 06 May 2011 18:03:46 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
In-reply-to: <jwvsjss2bz3.fsf-monnier+emacs@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Message-id: <83vcxnlvl9.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DC10012.8020809@HIDDEN>
	<E1QHYkc-0008Ip-Tq@HIDDEN>
	<4DC1692B.1090101@HIDDEN> <83ei4cnau6.fsf@HIDDEN>
	<jwvsjss2bz3.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, eggert@HIDDEN, emacs-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.1 (--)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Paul Eggert <eggert@HIDDEN>,  8545 <at> debbugs.gnu.org,  emacs-devel@HIDDEN
> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 6 May 2011 14:41:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 06 10:41:51 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QIME3-0005QM-CD
	for submit <at> 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 <eggert@HIDDEN>) id 1QIME1-0005QB-KT
	for 8545 <at> 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@HIDDEN>
Date: Fri, 06 May 2011 07:41:42 -0700
From: Paul Eggert <eggert@HIDDEN>
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
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN>
	<83tydmaeo3.fsf@HIDDEN>	<4DB65FF1.5010003@HIDDEN>
	<83aafb8p4a.fsf@HIDDEN>	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>	<4DB9E5FF.9020506@HIDDEN>
	<83d3k571ee.fsf@HIDDEN>	<4DC10012.8020809@HIDDEN>
	<E1QHYkc-0008Ip-Tq@HIDDEN>	<4DC1692B.1090101@HIDDEN>
	<83ei4cnau6.fsf@HIDDEN> <jwvsjss2bz3.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvsjss2bz3.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: Eli Zaretskii <eliz@HIDDEN>, 8545 <at> debbugs.gnu.org, emacs-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 6 May 2011 13:33:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 06 09:33:34 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QIL9y-0003he-EA
	for submit <at> 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 <monnier@HIDDEN>) id 1QIL9v-0003hN-0v
	for 8545 <at> 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 <monnier@HIDDEN>)
	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 <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
Message-ID: <jwvsjss2bz3.fsf-monnier+emacs@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN> <E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN> <E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DC10012.8020809@HIDDEN> <E1QHYkc-0008Ip-Tq@HIDDEN>
	<4DC1692B.1090101@HIDDEN> <83ei4cnau6.fsf@HIDDEN>
Date: Fri, 06 May 2011 10:33:21 -0300
In-Reply-To: <83ei4cnau6.fsf@HIDDEN> (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-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, emacs-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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
>> <http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00923.html>.
>> 
>> 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




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 6 May 2011 07:30:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 06 03:30:07 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QIFUE-00031P-AV
	for submit <at> 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 <eggert@HIDDEN>)
	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@HIDDEN>
Date: Fri, 06 May 2011 00:29:56 -0700
From: Paul Eggert <eggert@HIDDEN>
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
To: 8545 <at> debbugs.gnu.org, 8600-done <at> debbugs.gnu.org, 
	8601-done <at> debbugs.gnu.org, 8602-done <at> debbugs.gnu.org
Subject: Merged fixes for 8600, 8601, 8602, and (partially) for 8545
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 5 May 2011 20:36:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 05 16:36:58 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QI5IA-0005A3-Mh
	for submit <at> 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 <eliz@HIDDEN>) id 1QI5I7-00059q-VQ
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Thu, 05 May 2011 23:36:50 +0300 (IDT)
Date: Thu, 05 May 2011 23:36:49 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
In-reply-to: <4DC1692B.1090101@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Paul Eggert <eggert@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Message-id: <83ei4cnau6.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DC10012.8020809@HIDDEN>
	<E1QHYkc-0008Ip-Tq@HIDDEN>
	<4DC1692B.1090101@HIDDEN>
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, emacs-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.1 (--)

> Date: Wed, 04 May 2011 07:56:43 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: 8545 <at> debbugs.gnu.org, Emacs Development <emacs-devel@HIDDEN>
> 
> 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
> <http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00923.html>.
> 
> 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?




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 4 May 2011 14:56:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 04 10:56:54 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QHdVV-0005bM-D1
	for submit <at> 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 <eggert@HIDDEN>) id 1QHdVT-0005b9-Cu
	for 8545 <at> 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@HIDDEN>
Date: Wed, 04 May 2011 07:56:43 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DC10012.8020809@HIDDEN>
	<E1QHYkc-0008Ip-Tq@HIDDEN>
In-Reply-To: <E1QHYkc-0008Ip-Tq@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, Emacs Development <emacs-devel@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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
<http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00923.html>.

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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 4 May 2011 09:52:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 04 05:52:19 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QHYkk-0006Kc-OL
	for submit <at> 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 <eliz@HIDDEN>) id 1QHYki-0006KO-AU
	for 8545 <at> 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 <eliz@HIDDEN>)
	id 1QHYkc-0008Ip-Tq; Wed, 04 May 2011 05:52:10 -0400
Date: Wed, 04 May 2011 05:52:10 -0400
Message-Id: <E1QHYkc-0008Ip-Tq@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DC10012.8020809@HIDDEN> (message from Paul Eggert on Wed, 
	04 May 2011 00:28:18 -0700)
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DC10012.8020809@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.6 (------)

> Date: Wed, 04 May 2011 00:28:18 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: 8545 <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 4 May 2011 07:28:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 04 03:28:29 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QHWVZ-0002oo-2k
	for submit <at> 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 <eggert@HIDDEN>) id 1QHWVW-0002oW-Sg
	for 8545 <at> 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@HIDDEN>
Date: Wed, 04 May 2011 00:28:18 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
In-Reply-To: <83d3k571ee.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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  <eggert@HIDDEN>
 
+	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  <eggert@HIDDEN>
 
+	* 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 <stdarg.h>, as <lisp.h> does that.
+
 	Arithmetic overflows now return float rather than wrapping around.
 	(Bug#8611).
 	* data.c: Include <intprops.h>.

=== 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 <sys/file.h>
 #include <unistd.h>
 #include <signal.h>
-#include <stdarg.h>
 #include <setjmp.h>
 
 #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);
 }





Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 3 May 2011 20:24:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 03 16:24:27 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QHM8w-0004fg-Oy
	for submit <at> 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 <eggert@HIDDEN>) id 1QHM8t-0004fU-LR
	for 8545 <at> 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@HIDDEN>
Date: Tue, 03 May 2011 13:24:16 -0700
From: Paul Eggert <eggert@HIDDEN>
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
To: rms@HIDDEN
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN>	<83tydmaeo3.fsf@HIDDEN>	<4DB65FF1.5010003@HIDDEN>	<83aafb8p4a.fsf@HIDDEN>	<4DB8ABEA.3080503@HIDDEN>	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>	<4DB8DAF8.7070408@HIDDEN>	<E1QFmoF-0003nE-7o@HIDDEN>	<4DBB4E80.2020102@HIDDEN>	<E1QGHKN-0008I1-9A@HIDDEN>	<4DBCF292.4030002@HIDDEN>	<E1QGgXa-0000Fo-BP@HIDDEN>
	<4DBDF989.8070500@HIDDEN>
	<E1QH37h-0001yM-HR@HIDDEN>
In-Reply-To: <E1QH37h-0001yM-HR@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.2 (---)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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 <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8611>;
its patch uses code like the following.


#include <limits.h>

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);
}




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 2 May 2011 00:23:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 01 20:23:48 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QGgvU-0007wu-5F
	for submit <at> 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 <eggert@HIDDEN>) id 1QGgvR-0007wh-IA
	for 8545 <at> 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@HIDDEN>
Date: Sun, 01 May 2011 17:23:37 -0700
From: Paul Eggert <eggert@HIDDEN>
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: rms@HIDDEN
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN>
	<83tydmaeo3.fsf@HIDDEN>	<4DB65FF1.5010003@HIDDEN>
	<83aafb8p4a.fsf@HIDDEN>	<4DB8ABEA.3080503@HIDDEN>	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFmoF-0003nE-7o@HIDDEN>
	<4DBB4E80.2020102@HIDDEN>
	<E1QGHKN-0008I1-9A@HIDDEN>
	<4DBCF292.4030002@HIDDEN>
	<E1QGgXa-0000Fo-BP@HIDDEN>
In-Reply-To: <E1QGgXa-0000Fo-BP@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 1 May 2011 23:59:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 01 19:59:14 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QGgXh-0007Ob-O3
	for submit <at> 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 <rms@HIDDEN>) id 1QGgXf-0007OP-Pn
	for 8545 <at> 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 <rms@HIDDEN>)
	id 1QGgXa-0000Fo-BP; Sun, 01 May 2011 19:59:06 -0400
Date: Sun, 01 May 2011 19:59:06 -0400
Message-Id: <E1QGgXa-0000Fo-BP@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15
From: Richard Stallman <rms@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DBCF292.4030002@HIDDEN> (message from Paul Eggert on Sat, 
	30 Apr 2011 22:41:38 -0700)
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN>
	<83tydmaeo3.fsf@HIDDEN>	<4DB65FF1.5010003@HIDDEN>
	<83aafb8p4a.fsf@HIDDEN>	<4DB8ABEA.3080503@HIDDEN>	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFmoF-0003nE-7o@HIDDEN>
	<4DBB4E80.2020102@HIDDEN>
	<E1QGHKN-0008I1-9A@HIDDEN>
	<4DBCF292.4030002@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: rms@HIDDEN
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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/




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 1 May 2011 11:02:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 01 07:02:24 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QGUPw-0006KR-46
	for submit <at> 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 <whitebox@HIDDEN>) id 1QGUPs-0006KE-LR
	for 8545 <at> 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 <schwab@HIDDEN>
To: Jason Rumney <jasonr@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN> <E1QFmoF-0003nE-7o@HIDDEN>
	<4DBB4E80.2020102@HIDDEN> <87vcxvjbcm.fsf@HIDDEN>
	<4DBCF61D.50000@HIDDEN> <87pqo2kfex.fsf@HIDDEN>
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@HIDDEN> (Jason Rumney's message of "Sun, 01 May
	2011 16:12:38 +0800")
Message-ID: <m2fwoy4rbe.fsf@HIDDEN>
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-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>,
	rms@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)

Jason Rumney <jasonr@HIDDEN> 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@HIDDEN
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 1 May 2011 08:12:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 01 04:12:56 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QGRlv-0002D8-TG
	for submit <at> 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 <jasonrumney@HIDDEN>) id 1QGRlt-0002Cv-BM
	for 8545 <at> debbugs.gnu.org; Sun, 01 May 2011 04:12:53 -0400
Received: by pvh1 with SMTP id 1so3139139pvh.3
	for <8545 <at> 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 <jasonr@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN> <E1QFmoF-0003nE-7o@HIDDEN>
	<4DBB4E80.2020102@HIDDEN> <87vcxvjbcm.fsf@HIDDEN>
	<4DBCF61D.50000@HIDDEN>
Date: Sun, 01 May 2011 16:12:38 +0800
In-Reply-To: <4DBCF61D.50000@HIDDEN> (Paul Eggert's message of "Sat, 30
	Apr 2011 22:56:45 -0700")
Message-ID: <87pqo2kfex.fsf@HIDDEN>
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-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org, rms@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.6 (---)

Paul Eggert <eggert@HIDDEN> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 1 May 2011 05:56:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 01 01:56:54 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QGPeH-0007g1-SK
	for submit <at> 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 <eggert@HIDDEN>) id 1QGPeF-0007fp-QK
	for 8545 <at> 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@HIDDEN>
Date: Sat, 30 Apr 2011 22:56:45 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Jason Rumney <jasonr@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN>
	<83tydmaeo3.fsf@HIDDEN>	<4DB65FF1.5010003@HIDDEN>
	<83aafb8p4a.fsf@HIDDEN>	<4DB8ABEA.3080503@HIDDEN>	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>	<4DB8DAF8.7070408@HIDDEN>
	<E1QFmoF-0003nE-7o@HIDDEN>	<4DBB4E80.2020102@HIDDEN>
	<87vcxvjbcm.fsf@HIDDEN>
In-Reply-To: <87vcxvjbcm.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org, rms@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 1 May 2011 05:41:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 01 01:41:47 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QGPPf-0007Lk-Hy
	for submit <at> 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 <eggert@HIDDEN>) id 1QGPPd-0007LY-Dn
	for 8545 <at> 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@HIDDEN>
Date: Sat, 30 Apr 2011 22:41:38 -0700
From: Paul Eggert <eggert@HIDDEN>
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: rms@HIDDEN
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN>
	<83tydmaeo3.fsf@HIDDEN>	<4DB65FF1.5010003@HIDDEN>
	<83aafb8p4a.fsf@HIDDEN>	<4DB8ABEA.3080503@HIDDEN>	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFmoF-0003nE-7o@HIDDEN>
	<4DBB4E80.2020102@HIDDEN>
	<E1QGHKN-0008I1-9A@HIDDEN>
In-Reply-To: <E1QGHKN-0008I1-9A@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 1 May 2011 04:26:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 01 00:26:01 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QGOEL-0005iM-1x
	for submit <at> 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 <jasonrumney@HIDDEN>) id 1QGOEJ-0005i9-3V
	for 8545 <at> debbugs.gnu.org; Sun, 01 May 2011 00:25:59 -0400
Received: by pxi9 with SMTP id 9so1635019pxi.0
	for <8545 <at> 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 <jasonr@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN> <E1QFmoF-0003nE-7o@HIDDEN>
	<4DBB4E80.2020102@HIDDEN>
Date: Sun, 01 May 2011 12:25:45 +0800
In-Reply-To: <4DBB4E80.2020102@HIDDEN> (Paul Eggert's message of "Fri, 29
	Apr 2011 16:49:20 -0700")
Message-ID: <87vcxvjbcm.fsf@HIDDEN>
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-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org, rms@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.6 (---)

Paul Eggert <eggert@HIDDEN> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 30 Apr 2011 21:04:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 30 17:04:02 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QGHKb-0004f0-1Q
	for submit <at> 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 <rms@HIDDEN>) id 1QGHKX-0004en-Qf
	for 8545 <at> 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 <rms@HIDDEN>)
	id 1QGHKN-0008I1-9A; Sat, 30 Apr 2011 17:03:47 -0400
Date: Sat, 30 Apr 2011 17:03:47 -0400
Message-Id: <E1QGHKN-0008I1-9A@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15
From: Richard Stallman <rms@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DBB4E80.2020102@HIDDEN> (message from Paul Eggert on Fri, 
	29 Apr 2011 16:49:20 -0700)
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN>
	<83tydmaeo3.fsf@HIDDEN>	<4DB65FF1.5010003@HIDDEN>
	<83aafb8p4a.fsf@HIDDEN>	<4DB8ABEA.3080503@HIDDEN>	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFmoF-0003nE-7o@HIDDEN>
	<4DBB4E80.2020102@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: rms@HIDDEN
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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/




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 30 Apr 2011 09:00:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 30 05:00:00 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QG61w-0003rw-Dn
	for submit <at> 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 <eliz@HIDDEN>) id 1QG61u-0003rj-Gv
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Sat, 30 Apr 2011 11:59:16 +0300 (IDT)
Date: Sat, 30 Apr 2011 11:59:18 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
In-reply-to: <4DBB205D.6050406@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Paul Eggert <eggert@HIDDEN>
Message-id: <83r58k5d3t.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DBACE24.5080803@HIDDEN> <83zkn86eaz.fsf@HIDDEN>
	<4DBB205D.6050406@HIDDEN>
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.1 (--)

> Date: Fri, 29 Apr 2011 13:32:29 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: 8545 <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 23:49:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 29 19:49:29 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFxRB-0008Lr-Bc
	for submit <at> 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 <eggert@HIDDEN>) id 1QFxR9-0008Lf-3c
	for 8545 <at> 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@HIDDEN>
Date: Fri, 29 Apr 2011 16:49:20 -0700
From: Paul Eggert <eggert@HIDDEN>
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
To: rms@HIDDEN
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN>
	<83tydmaeo3.fsf@HIDDEN>	<4DB65FF1.5010003@HIDDEN>
	<83aafb8p4a.fsf@HIDDEN>	<4DB8ABEA.3080503@HIDDEN>	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFmoF-0003nE-7o@HIDDEN>
In-Reply-To: <E1QFmoF-0003nE-7o@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.2 (---)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.





Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 20:32:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 29 16:32:38 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFuMf-0002Qa-O1
	for submit <at> 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 <eggert@HIDDEN>) id 1QFuMd-0002QO-W7
	for 8545 <at> 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@HIDDEN>
Date: Fri, 29 Apr 2011 13:32:29 -0700
From: Paul Eggert <eggert@HIDDEN>
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
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DBACE24.5080803@HIDDEN> <83zkn86eaz.fsf@HIDDEN>
In-Reply-To: <83zkn86eaz.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.2 (---)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 19:56:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 29 15:56:55 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFto7-0001cX-OK
	for submit <at> 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 <eliz@HIDDEN>) id 1QFto5-0001cL-TC
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Fri, 29 Apr 2011 22:56:38 +0300 (IDT)
Date: Fri, 29 Apr 2011 22:56:39 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
In-reply-to: <E1QFmoF-0003nE-7o@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: rms@HIDDEN
Message-id: <83wric6dc8.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFmoF-0003nE-7o@HIDDEN>
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org, eggert@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.1 (--)

> Date: Fri, 29 Apr 2011 08:28:35 -0400
> From: Richard Stallman <rms@HIDDEN>
> Cc: lekktu@HIDDEN, 8545 <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 19:35:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 29 15:35:58 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFtTq-00018g-0J
	for submit <at> 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 <eliz@HIDDEN>) id 1QFtTm-00018R-KB
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Fri, 29 Apr 2011 22:35:47 +0300 (IDT)
Date: Fri, 29 Apr 2011 22:35:48 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
In-reply-to: <4DBACE24.5080803@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Paul Eggert <eggert@HIDDEN>
Message-id: <83zkn86eaz.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
	<4DBACE24.5080803@HIDDEN>
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.1 (--)

> Date: Fri, 29 Apr 2011 07:41:40 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: 8545 <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 14:41:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 29 10:41:56 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFotI-0002w2-BS
	for submit <at> 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 <eggert@HIDDEN>) id 1QFotF-0002vp-U4
	for 8545 <at> 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@HIDDEN>
Date: Fri, 29 Apr 2011 07:41:40 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN> <83d3k571ee.fsf@HIDDEN>
In-Reply-To: <83d3k571ee.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 12:28:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 29 08:28:43 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFmoM-0008DE-Pk
	for submit <at> 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 <rms@HIDDEN>) id 1QFmoK-0008D2-NL
	for 8545 <at> 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 <rms@HIDDEN>)
	id 1QFmoF-0003nE-7o; Fri, 29 Apr 2011 08:28:35 -0400
Date: Fri, 29 Apr 2011 08:28:35 -0400
Message-Id: <E1QFmoF-0003nE-7o@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15
From: Richard Stallman <rms@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DB8DAF8.7070408@HIDDEN> (message from Paul Eggert on Wed, 
	27 Apr 2011 20:11:52 -0700)
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: rms@HIDDEN
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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/




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 29 Apr 2011 11:17:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 29 07:17:39 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFlha-0005q8-Pt
	for submit <at> 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 <eliz@HIDDEN>) id 1QFlhY-0005pv-O9
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Fri, 29 Apr 2011 14:16:57 +0300 (IDT)
Date: Fri, 29 Apr 2011 14:16:57 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
In-reply-to: <4DB9E5FF.9020506@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Paul Eggert <eggert@HIDDEN>
Message-id: <83d3k571ee.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
	<4DB9E5FF.9020506@HIDDEN>
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.1 (--)

> Date: Thu, 28 Apr 2011 15:11:11 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: 8545-done <at> 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 ;-)




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.
Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <help-debbugs@HIDDEN> to internal_control <at> debbugs.gnu.org. Full text available.

Message received at 8545-done <at> debbugs.gnu.org:


Received: (at 8545-done) by debbugs.gnu.org; 28 Apr 2011 22:11:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 18:11:22 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFZQf-0004Wc-Mt
	for submit <at> debbugs.gnu.org; Thu, 28 Apr 2011 18:11:22 -0400
Received: from smtp.cs.ucla.edu ([131.179.128.62])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <eggert@HIDDEN>) id 1QFZQd-0004WP-2H
	for 8545-done <at> debbugs.gnu.org; Thu, 28 Apr 2011 18:11:20 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp.cs.ucla.edu (Postfix) with ESMTP id 837B739E8106;
	Thu, 28 Apr 2011 15:11:13 -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 8H7JjaUiipfq; Thu, 28 Apr 2011 15:11:12 -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 6F4CD39E80F8;
	Thu, 28 Apr 2011 15:11:12 -0700 (PDT)
Message-ID: <4DB9E5FF.9020506@HIDDEN>
Date: Thu, 28 Apr 2011 15:11:11 -0700
From: Paul Eggert <eggert@HIDDEN>
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
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
	<E1QFQVO-0004Dq-6o@HIDDEN>
In-Reply-To: <E1QFQVO-0004Dq-6o@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.2 (---)
X-Debbugs-Envelope-To: 8545-done
Cc: 8545-done <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.2 (---)

> 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.


>>>> * 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?
>>
>> Yes, absolutely.  The bug happens on the platform I normally develop
>> Emacs on, namely RHEL 5.6 (x86-64).
>
> What is the implementation of va_start on that platform?

Sorry, I don't know.

> Is stashing away the ap argument all that's required here?

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.


> You don't need me to reopen a bug, and you don't need an open bug
> report to work on some code, if you feel like it.

OK, thanks, I'll see if I can reopen the bug and install a fix or two.


>>>>  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'?
>>
>> n * 10 cannot possibly be SIZE_MAX - 1, because at that
>> point n < SIZE_MAX / 10, which means n * 10 is at most
>> SIZE_MAX - SIZE_MAX % 10 - 10.  fmt[1] is an ASCII digit,
>> so n * 10 therefore cannot possibly be greater than
>> SIZE_MAX - (fmt[1] - '0').  Hence the expression
>> n * 10 > SIZE_MAX - (fmt[1] - '0') always returns zero.
>
> So now you suddenly realize that the ">=" in the first part of that if
> clause was a good idea after all, yes?

I already indicated that I understand how that first part works, in
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545#26>.  But with the
">=" in place, the second part of that 'if' clause always returns 0:
that's unnecessarily confusing, since it misleads the reader into
thinking that the second part is needed, when it's not.

In other words, if "digit" is in the range 0 through 9, then this:

   if (n > SIZE_MAX / 10 || n * 10 > SIZE_MAX - digit) error (...);

is exact but complicated, and this:

   if (n >= SIZE_MAX / 10) error (...);

is simple but slightly conservative (it reports overflow for a few
very large but not overflowed numbers, but that's good enough here).
Finally, this:

   if (n >= SIZE_MAX / 10 || n * 10 > SIZE_MAX - digit) error (...);

is is neither exact nor simple, and is more confusing than either of
the above; there's nothing to recommend it over the other two.

Also, as I mentioned earlier, the code should also check for 'int'
overflow, as most sprintf implementations mess up with widths or
precisions greater than INT_MAX.  I'll check in a fix for that, with a
comment that tries to explain the situation and responds to your other
remarks about clarity here; please feel free to improve it.

Another possibility is to remove the 'if' test entirely, making it the
caller's responsibility to not specify outlandish widths in format
strings.  That would make the code simpler yet.  The other overflow
checks in doprnt would have to stay, since they depend on user data,
but this overflow check is superfluous.


> The issue is not whether it includes the null or not.  The issue is
> the range of values that an EMACS_INT data type must be able to
> represent, and the relation of that range to the maximum number of
> bytes in a string and to the largest possible string byte position
> that Emacs is able to handle.

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.

Is it also the case that Emacs should limit strings to at most
MOST_POSITIVE_FIXNUM - 1 bytes?  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.

If so, then should this doprnt code:

              tem = strlen (string);
              if (tem > MOST_POSITIVE_FIXNUM)
                error ("Format width or precision too large");
 
use ">=" rather than ">"?  There are two instances of this
sort of thing.




Message received at 8545-done <at> debbugs.gnu.org:


Received: (at 8545-done) by debbugs.gnu.org; 28 Apr 2011 12:39:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 08:39:47 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFQVW-0008Oj-HD
	for submit <at> debbugs.gnu.org; Thu, 28 Apr 2011 08:39:46 -0400
Received: from fencepost.gnu.org ([140.186.70.10])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <eliz@HIDDEN>) id 1QFQVT-0008OW-Cc
	for 8545-done <at> debbugs.gnu.org; Thu, 28 Apr 2011 08:39:44 -0400
Received: from eliz by fencepost.gnu.org with local (Exim 4.71)
	(envelope-from <eliz@HIDDEN>)
	id 1QFQVO-0004Dq-6o; Thu, 28 Apr 2011 08:39:38 -0400
Date: Thu, 28 Apr 2011 08:39:38 -0400
Message-Id: <E1QFQVO-0004Dq-6o@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DB9146D.2040702@HIDDEN> (message from Paul Eggert on Thu, 
	28 Apr 2011 00:17:01 -0700)
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
	<4DB9146D.2040702@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545-done
Cc: 8545-done <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.6 (------)

> Date: Thu, 28 Apr 2011 00:17:01 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: 8545-done <at> debbugs.gnu.org
> 
> On 04/27/11 22:50, Eli Zaretskii wrote:
> 
> >> * 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? 
> 
> Yes, absolutely.  The bug happens on the platform I normally develop
> Emacs on, namely RHEL 5.6 (x86-64).

What is the implementation of va_start on that platform?  Is stashing
away the ap argument all that's required here?

> > 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.
> 
> It's not merely a question of the format string itself.
> It could be that there's an error message that formats long file names
> that contain non-ASCII characters, or something else like that;
> the point is that the file names themselves are not under the Emacs
> programmer's control.

If that's what you mean, it's easy to fix.  Done.

> > I'm closing this bug.
> 
> That doesn't sound right.  doprnt has real bugs, which will bite
> users when they process large but plausible strings.  These bugs
> should be fixed.  Could you please reopen the bug report?

You don't need me to reopen a bug, and you don't need an open bug
report to work on some code, if you feel like it.

> > all because of your stubborn insistence on using a library
> > function where it doesn't fit the bill.
> 
> This misrepresents my position.  I already agreed with
> you that it's OK for Emacs to use its own doprnt function
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8435#58>,
> and I have not insisted on using any particular library function.
> Please don't personalize this bug report with phrases like
> "your stubborn insistence", and please do not ascribe to me
> motivations that I do not have.

I have no idea what are your motivations.  All I know is what you
write and I read, and how you act.  I see that and I make my
conclusions.  If you don't want your positions misrepresented, try
making your words and deeds speak unequivocally about them.  E.g., try
insisting less that you are always right and others are always wrong,
when judging merits and demerits of alternative solutions to problems.

IOW, this is primarily a social activity.  Good spirit around here can
easily be destroyed by lack of respect to dissenting opinions.  Trying
to reach some kind of consensus, and if that's not possible, some
compromise, is a much better way of having your positions and your
motivations respected.

And that is the last time I'm talking about this in this regard.

> >>  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'?
> 
> n * 10 cannot possibly be SIZE_MAX - 1, because at that
> point n < SIZE_MAX / 10, which means n * 10 is at most
> SIZE_MAX - SIZE_MAX % 10 - 10.  fmt[1] is an ASCII digit,
> so n * 10 therefore cannot possibly be greater than
> SIZE_MAX - (fmt[1] - '0').  Hence the expression
> n * 10 > SIZE_MAX - (fmt[1] - '0') always returns zero.

So now you suddenly realize that the ">=" in the first part of that if
clause was a good idea after all, yes?

> >>   /* 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.
> 
> It's clearer because it says that it's intended that the test is
> conservative

The intent of the test is clear, but its relation to what is done if
the test succeeds is not.

> and that the test might sometimes err on the side of rejecting
> widths or precisions even though they are not too large for the code
> to represent.

Precisely my motivation to include a possibly redundant test which you
so eloquently argue against above.  Can we have some consistency here,
please?  Can you please judge your own arguments like you judge those
of others?

> >> Emacs size fields count the bytes in the string, and does not
> >> count the terminating null byte (which is not part of the string).
> > 
> > String positions are zero-based and extend to
> > include the terminating null character.  See the relevant parts of the
> > display engine code.
> 
> Yes, a position can point to the terminating null character, but if that
> position is N, then the string contains N bytes (not counting the
> terminating null).

The issue is not whether it includes the null or not.  The issue is
the range of values that an EMACS_INT data type must be able to
represent, and the relation of that range to the maximum number of
bytes in a string and to the largest possible string byte position
that Emacs is able to handle.

> Could you please identify a part of the display engine code that is
> going past the terminating null character, so that I can understand
> the situation better?

Start with reseat_to_string and then read (the relevant parts of)
set_iterator_to_next and next_element_from_c_string, for example.




Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 11:14:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 07:14:23 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFPAs-0005eU-Io
	for submit <at> 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 <eliz@HIDDEN>) id 1QFPAq-0005eI-8Y
	for 8545 <at> 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 <eliz@HIDDEN>)
	id 1QFPAk-00082P-JM; Thu, 28 Apr 2011 07:14:14 -0400
Date: Thu, 28 Apr 2011 07:14:14 -0400
Message-Id: <E1QFPAk-00082P-JM@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DB91D2D.5080008@HIDDEN> (message from Paul Eggert on Thu, 
	28 Apr 2011 00:54:21 -0700)
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFJZY-0007Sr-8c@HIDDEN>
	<4DB8FB35.5090205@HIDDEN>
	<E1QFKRD-0001nu-So@HIDDEN>
	<4DB90C71.6060804@HIDDEN>
	<E1QFLcK-0006Sx-Bc@HIDDEN>
	<4DB91D2D.5080008@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.6 (------)

> Date: Thu, 28 Apr 2011 00:54:21 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: lekktu@HIDDEN, 8545 <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 07:54:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 03:54:38 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFM3Z-000192-V0
	for submit <at> 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 <eggert@HIDDEN>) id 1QFM3X-00018r-Vo
	for 8545 <at> 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@HIDDEN>
Date: Thu, 28 Apr 2011 00:54:21 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFJZY-0007Sr-8c@HIDDEN>
	<4DB8FB35.5090205@HIDDEN>
	<E1QFKRD-0001nu-So@HIDDEN>
	<4DB90C71.6060804@HIDDEN>
	<E1QFLcK-0006Sx-Bc@HIDDEN>
In-Reply-To: <E1QFLcK-0006Sx-Bc@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 07:26:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 03:26:35 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFLcR-0000Wl-Jh
	for submit <at> 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 <eliz@HIDDEN>) id 1QFLcP-0000WY-JT
	for 8545 <at> 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 <eliz@HIDDEN>)
	id 1QFLcK-0006Sx-Bc; Thu, 28 Apr 2011 03:26:28 -0400
Date: Thu, 28 Apr 2011 03:26:28 -0400
Message-Id: <E1QFLcK-0006Sx-Bc@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DB90C71.6060804@HIDDEN> (message from Paul Eggert on Wed, 
	27 Apr 2011 23:42:57 -0700)
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFJZY-0007Sr-8c@HIDDEN>
	<4DB8FB35.5090205@HIDDEN>
	<E1QFKRD-0001nu-So@HIDDEN>
	<4DB90C71.6060804@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.6 (------)

> Date: Wed, 27 Apr 2011 23:42:57 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: lekktu@HIDDEN, 8545 <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545-done <at> debbugs.gnu.org:


Received: (at 8545-done) by debbugs.gnu.org; 28 Apr 2011 07:17:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 03:17:11 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFLTL-0000IK-Hm
	for submit <at> debbugs.gnu.org; Thu, 28 Apr 2011 03:17:11 -0400
Received: from smtp.cs.ucla.edu ([131.179.128.62])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <eggert@HIDDEN>) id 1QFLTJ-0000I9-GA
	for 8545-done <at> debbugs.gnu.org; Thu, 28 Apr 2011 03:17:10 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp.cs.ucla.edu (Postfix) with ESMTP id DAA4D39E80FA;
	Thu, 28 Apr 2011 00:17:03 -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 4fHR69-ZNP1I; Thu, 28 Apr 2011 00:17:02 -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 1467139E8082;
	Thu, 28 Apr 2011 00:17:02 -0700 (PDT)
Message-ID: <4DB9146D.2040702@HIDDEN>
Date: Thu, 28 Apr 2011 00:17:01 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<E1QFK7p-0000de-I3@HIDDEN>
In-Reply-To: <E1QFK7p-0000de-I3@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545-done
Cc: 8545-done <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.0 (---)

On 04/27/11 22:50, Eli Zaretskii wrote:

>> * 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? 

Yes, absolutely.  The bug happens on the platform I normally develop
Emacs on, namely RHEL 5.6 (x86-64).

> 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.

It's not merely a question of the format string itself.
It could be that there's an error message that formats long file names
that contain non-ASCII characters, or something else like that;
the point is that the file names themselves are not under the Emacs
programmer's control.

And anyway, verror should not have arbitrary limits like 4000 bytes;
that's too small.

> I'm closing this bug.

That doesn't sound right.  doprnt has real bugs, which will bite
users when they process large but plausible strings.  These bugs
should be fixed.  Could you please reopen the bug report?

> all because of your stubborn insistence on using a library
> function where it doesn't fit the bill.

This misrepresents my position.  I already agreed with
you that it's OK for Emacs to use its own doprnt function
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8435#58>,
and I have not insisted on using any particular library function.
Please don't personalize this bug report with phrases like
"your stubborn insistence", and please do not ascribe to me
motivations that I do not have.

>>  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'?

n * 10 cannot possibly be SIZE_MAX - 1, because at that
point n < SIZE_MAX / 10, which means n * 10 is at most
SIZE_MAX - SIZE_MAX % 10 - 10.  fmt[1] is an ASCII digit,
so n * 10 therefore cannot possibly be greater than
SIZE_MAX - (fmt[1] - '0').  Hence the expression
n * 10 > SIZE_MAX - (fmt[1] - '0') always returns 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.

It's clearer because it says that it's intended that the test is
conservative, and that the test might sometimes err on the side of
rejecting widths or precisions even though they are not too large
for the code to represent.  Currently, this is not clear from the
code and its comments.

>> Emacs size fields count the bytes in the string, and does not
>> count the terminating null byte (which is not part of the string).
> 
> String positions are zero-based and extend to
> include the terminating null character.  See the relevant parts of the
> display engine code.

Yes, a position can point to the terminating null character, but if that
position is N, then the string contains N bytes (not counting the
terminating null).  So I still don't see the problem here.  Could you
please identify a part of the display engine code that is going past
the terminating null character, so that I can understand the situation
better?




Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 06:43:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 02:43:08 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFKwO-0006aw-0c
	for submit <at> 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 <eggert@HIDDEN>) id 1QFKwK-0006aM-Qt
	for 8545 <at> 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@HIDDEN>
Date: Wed, 27 Apr 2011 23:42:57 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFJZY-0007Sr-8c@HIDDEN>
	<4DB8FB35.5090205@HIDDEN>
	<E1QFKRD-0001nu-So@HIDDEN>
In-Reply-To: <E1QFKRD-0001nu-So@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 06:11:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 02:11:02 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFKRK-0005nj-FR
	for submit <at> 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 <eliz@HIDDEN>) id 1QFKRJ-0005nC-6d
	for 8545 <at> 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 <eliz@HIDDEN>)
	id 1QFKRD-0001nu-So; Thu, 28 Apr 2011 02:10:55 -0400
Date: Thu, 28 Apr 2011 02:10:55 -0400
Message-Id: <E1QFKRD-0001nu-So@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DB8FB35.5090205@HIDDEN> (message from Paul Eggert on Wed, 
	27 Apr 2011 22:29:25 -0700)
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFJZY-0007Sr-8c@HIDDEN>
	<4DB8FB35.5090205@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.6 (------)

> Date: Wed, 27 Apr 2011 22:29:25 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: lekktu@HIDDEN, 8545 <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545-done <at> debbugs.gnu.org:


Received: (at 8545-done) by debbugs.gnu.org; 28 Apr 2011 05:51:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 01:51:01 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFK7x-0005KN-0v
	for submit <at> 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 <eliz@HIDDEN>) id 1QFK7v-0005K9-K0
	for 8545-done <at> 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 <eliz@HIDDEN>)
	id 1QFK7p-0000de-I3; Thu, 28 Apr 2011 01:50:53 -0400
Date: Thu, 28 Apr 2011 01:50:53 -0400
Message-Id: <E1QFK7p-0000de-I3@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DB8ABEA.3080503@HIDDEN> (message from Paul Eggert on Wed, 
	27 Apr 2011 16:51:06 -0700)
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545-done
Cc: 8545-done <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.6 (------)

> Date: Wed, 27 Apr 2011 16:51:06 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: 8545 <at> 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.




Notification sent to Paul Eggert <eggert@HIDDEN>:
bug acknowledged by developer. Full text available.
Reply sent to Eli Zaretskii <eliz@HIDDEN>:
You have taken responsibility. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:29:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 01:29:36 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFJnD-0004qU-CE
	for submit <at> 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 <eggert@HIDDEN>) id 1QFJnA-0004qJ-Fe
	for 8545 <at> 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@HIDDEN>
Date: Wed, 27 Apr 2011 22:29:25 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<E1QFJZY-0007Sr-8c@HIDDEN>
In-Reply-To: <E1QFJZY-0007Sr-8c@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:15:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 01:15:36 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFJZg-0004XA-1M
	for submit <at> 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 <eliz@HIDDEN>) id 1QFJZe-0004Wt-2a
	for 8545 <at> 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 <eliz@HIDDEN>)
	id 1QFJZY-0007Sr-8c; Thu, 28 Apr 2011 01:15:28 -0400
Date: Thu, 28 Apr 2011 01:15:28 -0400
Message-Id: <E1QFJZY-0007Sr-8c@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <4DB8DAF8.7070408@HIDDEN> (message from Paul Eggert on Wed, 
	27 Apr 2011 20:11:52 -0700)
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545
Cc: lekktu@HIDDEN, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.6 (------)

> Date: Wed, 27 Apr 2011 20:11:52 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: Eli Zaretskii <eliz@HIDDEN>, 8545 <at> 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!




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:06:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 01:06:33 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFJQv-0004K5-JH
	for submit <at> 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 <eggert@HIDDEN>) id 1QFJQt-0004Jq-8Q
	for 8545 <at> 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@HIDDEN>
Date: Wed, 27 Apr 2011 22:06:23 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Juanma Barranquero <lekktu@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
	<BANLkTi=UGn8bKrixk5HmqbO4psPNNSjw0A@HIDDEN>
In-Reply-To: <BANLkTi=UGn8bKrixk5HmqbO4psPNNSjw0A@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: Eli Zaretskii <eliz@HIDDEN>, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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
<http://www.c-faq.com/aryptr/non0based.html>.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 05:02:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 01:02:21 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFJMr-0004Dr-3s
	for submit <at> 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 <eliz@HIDDEN>) id 1QFJMp-0004De-Me
	for 8545 <at> 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 <eliz@HIDDEN>)
	id 1QFJMj-0006tz-IO; Thu, 28 Apr 2011 01:02:13 -0400
Date: Thu, 28 Apr 2011 01:02:13 -0400
Message-Id: <E1QFJMj-0006tz-IO@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Juanma Barranquero <lekktu@HIDDEN>
In-reply-to: <BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN> (message
	from Juanma Barranquero on Thu, 28 Apr 2011 03:32:23 +0200)
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, eggert@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.6 (------)

> From: Juanma Barranquero <lekktu@HIDDEN>
> Date: Thu, 28 Apr 2011 03:32:23 +0200
> Cc: Eli Zaretskii <eliz@HIDDEN>, 8545 <at> debbugs.gnu.org
> 
> On Thu, Apr 28, 2011 at 01:51, Paul Eggert <eggert@HIDDEN> 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'.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 03:43:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 23:43:23 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFI8R-0002LR-EM
	for submit <at> 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 <lekktu@HIDDEN>) id 1QFI8L-0002L9-Lz
	for 8545 <at> debbugs.gnu.org; Wed, 27 Apr 2011 23:43:22 -0400
Received: by gyf3 with SMTP id 3so884337gyf.3
	for <8545 <at> 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@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
	<4DB8DAF8.7070408@HIDDEN>
From: Juanma Barranquero <lekktu@HIDDEN>
Date: Thu, 28 Apr 2011 05:42:32 +0200
Message-ID: <BANLkTi=UGn8bKrixk5HmqbO4psPNNSjw0A@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
To: Paul Eggert <eggert@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -3.3 (---)
X-Debbugs-Envelope-To: 8545
Cc: Eli Zaretskii <eliz@HIDDEN>, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.3 (---)

On Thu, Apr 28, 2011 at 05:11, Paul Eggert <eggert@HIDDEN> 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




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 03:12:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 23:12:02 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFHe6-0001dI-5n
	for submit <at> 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 <eggert@HIDDEN>) id 1QFHe3-0001ct-P9
	for 8545 <at> 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@HIDDEN>
Date: Wed, 27 Apr 2011 20:11:52 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Juanma Barranquero <lekktu@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
	<BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
In-Reply-To: <BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: Eli Zaretskii <eliz@HIDDEN>, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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





Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 28 Apr 2011 01:33:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 21:33:10 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFG6Q-0007o2-Lb
	for submit <at> 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 <lekktu@HIDDEN>) id 1QFG6O-0007ns-MD
	for 8545 <at> debbugs.gnu.org; Wed, 27 Apr 2011 21:33:09 -0400
Received: by yic13 with SMTP id 13so861618yic.3
	for <8545 <at> 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@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
	<4DB8ABEA.3080503@HIDDEN>
From: Juanma Barranquero <lekktu@HIDDEN>
Date: Thu, 28 Apr 2011 03:32:23 +0200
Message-ID: <BANLkTi=_735V1eMctO2-mnrs93KqbNDHzQ@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
To: Paul Eggert <eggert@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -3.3 (---)
X-Debbugs-Envelope-To: 8545
Cc: Eli Zaretskii <eliz@HIDDEN>, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.3 (---)

On Thu, Apr 28, 2011 at 01:51, Paul Eggert <eggert@HIDDEN> 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




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 27 Apr 2011 23:51:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 19:51:16 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFEVo-0005Uu-7s
	for submit <at> 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 <eggert@HIDDEN>) id 1QFEVl-0005Uh-JW
	for 8545 <at> 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@HIDDEN>
Date: Wed, 27 Apr 2011 16:51:06 -0700
From: Paul Eggert <eggert@HIDDEN>
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
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN> <83aafb8p4a.fsf@HIDDEN>
In-Reply-To: <83aafb8p4a.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.2 (---)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.





Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 27 Apr 2011 20:11:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 16:11:15 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QFB4s-0000SZ-SL
	for submit <at> 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 <eliz@HIDDEN>) id 1QFB4p-0000SK-7f
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Wed, 27 Apr 2011 22:34:41 +0300 (IDT)
Date: Wed, 27 Apr 2011 22:34:45 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
In-reply-to: <4DB65FF1.5010003@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Paul Eggert <eggert@HIDDEN>
Message-id: <83aafb8p4a.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<4DB65FF1.5010003@HIDDEN>
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.1 (--)

> Date: Mon, 25 Apr 2011 23:02:25 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: 8545 <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 27 Apr 2011 01:15:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 26 21:15:04 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QEtLM-0007LN-3b
	for submit <at> 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 <monnier@HIDDEN>) id 1QEtLJ-0007Kc-Tb
	for 8545 <at> 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 <monnier@HIDDEN>)
	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 <monnier@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
Message-ID: <jwvei4osdhu.fsf-monnier+emacs@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<jwvhb9m1mmh.fsf-monnier+emacs@HIDDEN> <4DB72A31.8040203@HIDDEN>
Date: Tue, 26 Apr 2011 22:14:54 -0300
In-Reply-To: <4DB72A31.8040203@HIDDEN> (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-Debbugs-Envelope-To: 8545
Cc: Eli Zaretskii <eliz@HIDDEN>, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 26 Apr 2011 20:25:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 26 16:25:31 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QEop9-0000it-8r
	for submit <at> 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 <eggert@HIDDEN>) id 1QEop5-0000ie-Us
	for 8545 <at> 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@HIDDEN>
Date: Tue, 26 Apr 2011 13:25:21 -0700
From: Paul Eggert <eggert@HIDDEN>
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
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
	<jwvhb9m1mmh.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvhb9m1mmh.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.2 (---)
X-Debbugs-Envelope-To: 8545
Cc: Eli Zaretskii <eliz@HIDDEN>, 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 26 Apr 2011 06:02:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 26 02:02:35 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QEbM2-0004f8-BA
	for submit <at> 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 <eggert@HIDDEN>) id 1QEbM0-0004ex-6x
	for 8545 <at> 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@HIDDEN>
Date: Mon, 25 Apr 2011 23:02:25 -0700
From: Paul Eggert <eggert@HIDDEN>
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: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
In-Reply-To: <83tydmaeo3.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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 +.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 25 Apr 2011 13:37:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 25 09:37:56 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QELz9-00078S-5T
	for submit <at> 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 <monnier@HIDDEN>) id 1QELz7-00078H-1I
	for 8545 <at> 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 <monnier@HIDDEN>)
	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 <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#8545: issues with recent doprnt-related changes
Message-ID: <jwvhb9m1mmh.fsf-monnier+emacs@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN> <83tydmaeo3.fsf@HIDDEN>
Date: Mon, 25 Apr 2011 10:37:44 -0300
In-Reply-To: <83tydmaeo3.fsf@HIDDEN> (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-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at 8545 <at> debbugs.gnu.org:


Received: (at 8545) by debbugs.gnu.org; 25 Apr 2011 09:00:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 25 05:00:58 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QEHf7-0000Fp-ML
	for submit <at> 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 <eliz@HIDDEN>) id 1QEHf4-0000Fb-Rs
	for 8545 <at> 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@HIDDEN> for
	8545 <at> 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@HIDDEN>;
	Mon, 25 Apr 2011 12:00:48 +0300 (IDT)
Date: Mon, 25 Apr 2011 12:00:44 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: issues with recent doprnt-related changes
In-reply-to: <4DB50AB9.6060100@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Paul Eggert <eggert@HIDDEN>
Message-id: <83tydmaeo3.fsf@HIDDEN>
References: <4DB50AB9.6060100@HIDDEN>
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 8545
Cc: 8545 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.0 (--)

> Date: Sun, 24 Apr 2011 22:46:33 -0700
> From: Paul Eggert <eggert@HIDDEN>
> CC: Eli Zaretskii <eliz@HIDDEN>
> 
> 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.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 25 Apr 2011 05:47:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 25 01:47:02 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1QEEdR-0004PJ-QA
	for submit <at> 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 <eggert@HIDDEN>) id 1QEEdP-0004Op-SU
	for submit <at> 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 <eggert@HIDDEN>) id 1QEEdJ-0000yv-RZ
	for submit <at> 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 <eggert@HIDDEN>) id 1QEEdJ-0000yq-Q4
	for submit <at> 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 <eggert@HIDDEN>) id 1QEEdI-0003LV-Ua
	for bug-gnu-emacs@HIDDEN; Mon, 25 Apr 2011 01:46:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <eggert@HIDDEN>) id 1QEEdH-0000yZ-Oi
	for bug-gnu-emacs@HIDDEN; 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 <eggert@HIDDEN>)
	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@HIDDEN>
Date: Sun, 24 Apr 2011 22:46:33 -0700
From: Paul Eggert <eggert@HIDDEN>
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@HIDDEN
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 <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> 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);




Acknowledgement sent to Paul Eggert <eggert@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:
bug#8545; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 31 Oct 2014 17:00:04 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.