From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Delayed loading of image libraries Date: Fri, 02 Jul 2004 17:59:50 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040702095920.CF37.JMBARRANQUERO@wke.es> <20040702103748.CF3D.JMBARRANQUERO@wke.es> Reply-To: Miles Bader NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1088758847 1437 80.91.224.253 (2 Jul 2004 09:00:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 2 Jul 2004 09:00:47 +0000 (UTC) Cc: Andreas Schwab , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Jul 02 11:00:38 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BgJuQ-0002Aj-00 for ; Fri, 02 Jul 2004 11:00:38 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BgJuQ-0002cu-00 for ; Fri, 02 Jul 2004 11:00:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BgJwE-0000Ov-BU for emacs-devel@quimby.gnus.org; Fri, 02 Jul 2004 05:02:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BgJvv-0000N7-Ff for emacs-devel@gnu.org; Fri, 02 Jul 2004 05:02:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BgJvs-0000MA-9V for emacs-devel@gnu.org; Fri, 02 Jul 2004 05:02:09 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BgJvs-0000Lt-1o for emacs-devel@gnu.org; Fri, 02 Jul 2004 05:02:08 -0400 Original-Received: from [202.32.8.214] (helo=TYO201.gate.nec.co.jp) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BgJu0-0000jz-LO; Fri, 02 Jul 2004 05:00:13 -0400 Original-Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.161] (may be forged)) by TYO201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i628xup19204; Fri, 2 Jul 2004 17:59:57 +0900 (JST) Original-Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i628xuq28139; Fri, 2 Jul 2004 17:59:56 +0900 (JST) Original-Received: from edsgm01.lsi.nec.co.jp ([10.50.208.11]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id i628xtU01767; Fri, 2 Jul 2004 17:59:55 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp (localhost [127.0.0.1]) by edsgm01.lsi.nec.co.jp (8.12.10/8.12.10) with ESMTP id i628xqkr023591; Fri, 2 Jul 2004 17:59:53 +0900 (JST) Original-Received: from mctpc71 (mctpc71.ucom.lsi.nec.co.jp [10.30.118.121]) by mcsss2.ucom.lsi.nec.co.jp (8.12.10/8.12.8/EDcg v2.01-mc/1046780839) with ESMTP id i628xpIm008635; Fri, 2 Jul 2004 17:59:51 +0900 (JST) Original-Received: by mctpc71 (Postfix, from userid 31295) id 0ED6448D; Fri, 2 Jul 2004 17:59:51 +0900 (JST) Original-To: Juanma Barranquero System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <20040702103748.CF3D.JMBARRANQUERO@wke.es> (Juanma Barranquero's message of "Fri, 02 Jul 2004 10:45:03 +0200") Original-Lines: 41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25386 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25386 Juanma Barranquero writes: >> If lookup_image_type returns null, at least valid_image_p should return >> 0 (after my change), and many places use that as a guard. Perhaps there >> are more places checks should be inserted -- but inserting such checks >> seems like the right thing to do. > > There are many places where valid_image_p is checked, like this one: > > make_image (spec, hash) > { ... > xassert (valid_image_p (spec)); ... > I don't think GLYPH_DEBUG is always defined, so xassert will do nothing. > But even if it did, asserting out of a function because you have a Lisp > value that cannot be *displayed* doesn't seem right. The decision rests > at a higher level about what to do with the value. A PNG on a non-PNG > Emacs shouldn't be non-valid; what it is, is not-available. Clearly if there are situations where a bogus image value placed by lisp can cause the an assertion failure, they should be fixed -- that should never happen. The C code _must_ deal with lisp providing invalid images in a non-crashing manner (by not displaying the image). However, it's possible that uses of valid_image_p such as the one you quote above rely on other C code to make sure an invalid image never reaches them, and the additional call to `xassert (valid_image_p (...))' is merely an additional safeguard to catch bugs earlier. You cannot know unless you trace through the situations where the function in question (such as make_image above) are called. A quick look shows that all the functions which use `xassert (valid_image_p (...))' (lookup_image_type, make_image, and image_spec_value) are only called in places where the image spec they use is guaranteed to be valid, because they are guarded by a previous call to valid_image_p. -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen