From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Delayed loading of image libraries Date: Fri, 02 Jul 2004 10:10:56 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040702095920.CF37.JMBARRANQUERO@wke.es> References: <20040702093521.CF34.JMBARRANQUERO@wke.es> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1088755894 26953 80.91.224.253 (2 Jul 2004 08:11:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 2 Jul 2004 08:11:34 +0000 (UTC) Cc: Andreas Schwab , David Kastrup , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Jul 02 10:11:21 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 1BgJ8i-0007Wu-00 for ; Fri, 02 Jul 2004 10:11:20 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BgJ8i-0001jC-00 for ; Fri, 02 Jul 2004 10:11:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BgJAW-00051S-7B for emacs-devel@quimby.gnus.org; Fri, 02 Jul 2004 04:13:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BgJAR-00050a-Jm for emacs-devel@gnu.org; Fri, 02 Jul 2004 04:13:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BgJAP-00050O-Sk for emacs-devel@gnu.org; Fri, 02 Jul 2004 04:13:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BgJAP-00050L-K5 for emacs-devel@gnu.org; Fri, 02 Jul 2004 04:13:05 -0400 Original-Received: from [62.22.181.117] (helo=idefix.laley.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BgJ8L-0007iP-NK; Fri, 02 Jul 2004 04:10:57 -0400 Original-Received: from [172.17.221.23] (JMBARRANQUERO [172.17.221.23]) by idefix.laley.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NZ3RGJD0; Fri, 2 Jul 2004 10:09:24 +0200 Original-To: Miles Bader In-Reply-To: X-Mailer: Becky! ver. 2.08.01 [en] 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:25379 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25379 On Fri, 02 Jul 2004 16:56:51 +0900 Miles Bader wrote: > I have no particular opinion about which exact function does it, but it > _should_ be done `transparently' -- that is any place where a lisp value > is used to compute deeper information (for display or otherwise). If it is done transparently, what to do when the image type is not available? You're worried about the case where you write an image and load it afterwards on the same Emacs, but in the general case, you can write an (image) lisp value with one Emacs and load it with another (which could not support the type). What's the expected behaviour at that point? If my reading of the code is right, when lookup_image_type returns NULL anything can happen. The code has a few xasserts here and there, but there's no real handling of NULL image types. Vide the current situation: when you try to load a TIFF, lookup_image_type returns NULL (because init-image-library is getting a null alist, but that's irrelevant to the argument). At some point, this return value is not checked and bingo! Emacs crashes (at least on Windows). > Both of those call `lookup_image_type', and thus > my placing a call to image-type-validation there. > > If I omitted an argument, obviously my change was flawed, but the > location seems reasonable. Perhaps you're right, I don't know. If you are right, then lookup_image_type would have to make sure that init-image-library is using image-library-alist, at which point the use of that variable is fixed in C code, and in fact no longer makes sense to pass it as an argument to init-image-library (it could as well be directly used from inside the function, as it is no longer overridable by the user). Juanma