Re: [PATCH] Delayed loading of image libraries

[Juanma Barranquero <jmbarranquero@wke.es>]

On Fri, 02 Jul 2004 16:56:51 +0900
Miles Bader <miles@lsi.nec.co.jp> 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