From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Subtle bugs in interval code. Date: Fri, 23 Mar 2007 12:55:15 +0100 Message-ID: <85d5302mzg.fsf@lola.goethe.zz> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1174650934 14001 80.91.229.12 (23 Mar 2007 11:55:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2007 11:55:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: storm@cua.dk (Kim F. Storm) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 12:55:28 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HUiMh-0001At-Bw for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2007 12:55:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUiOa-0003oi-NA for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2007 06:57:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HUiOV-0003j4-UB for emacs-devel@gnu.org; Fri, 23 Mar 2007 07:57:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HUiOT-0003bJ-Dd for emacs-devel@gnu.org; Fri, 23 Mar 2007 07:57:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUiOT-0003ag-3U for emacs-devel@gnu.org; Fri, 23 Mar 2007 06:57:17 -0500 Original-Received: from mail-in-10.arcor-online.net ([151.189.21.50]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HUiMY-0002UV-SZ for emacs-devel@gnu.org; Fri, 23 Mar 2007 07:55:19 -0400 Original-Received: from mail-in-02-z2.arcor-online.net (mail-in-02-z2.arcor-online.net [151.189.8.14]) by mail-in-10.arcor-online.net (Postfix) with ESMTP id 3B7D57C466; Fri, 23 Mar 2007 12:55:17 +0100 (CET) Original-Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mail-in-02-z2.arcor-online.net (Postfix) with ESMTP id 241311143CD; Fri, 23 Mar 2007 12:55:17 +0100 (CET) Original-Received: from lola.goethe.zz (dslb-084-061-035-141.pools.arcor-ip.net [84.61.35.141]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id B1AD819B323; Fri, 23 Mar 2007 12:55:16 +0100 (CET) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id C58A11C4F93F; Fri, 23 Mar 2007 12:55:15 +0100 (CET) In-Reply-To: (Kim F. Storm's message of "Fri\, 23 Mar 2007 12\:45\:38 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.96 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:68381 Archived-At: storm@cua.dk (Kim F. Storm) writes: > Studying the code in interval.c for merge_properties and > intervals_equal, I noticed that they use Fmemq to search > for a given property on a plist. > > That's not a safe way to do that; > > E.g. consider a plist like this: > > (setq p '(a b c d)) > > Now, > > (plist-get p 'a) => b > (plist-get p 'b) => nil > > whereas > > (memq 'a p) => (a b c d) > (memq 'b p) => (b c d) != nil > > So due to the use of Fmemq, the interval code may wrongly assume that > the plist has a `b' member with a value of `c'. > > I'm not aware of any specific bugs related to this. > > Note that we cannot just use plist-get instead of memq, as we then > cannot differentiate between "property is on list with nil value" > and "property is not on list". One could check whether the length of the rest sequence is even. The cleanest option might be to add an optional DEFAULT argument to plist-get, but that would require changes to all C level callers. Maybe one should add an explicit plist-get-default function that takes the default for non-existing elements from its third argument? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum