Re: [PATCH] Delayed loading of image libraries

[Miles Bader]

Juanma Barranquero <address@hidden> 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