[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Delayed loading of image libraries

From: Juanma Barranquero
Subject: Re: [PATCH] Delayed loading of image libraries
Date: Fri, 02 Jul 2004 10:45:03 +0200

On Fri, 02 Jul 2004 17:20:13 +0900
Miles Bader <address@hidden> wrote:

> That seems obvious -- just don't display it.

> 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:

static struct image *
make_image (spec, hash)
     Lisp_Object spec;
     unsigned hash;
  struct image *img = (struct image *) xmalloc (sizeof *img);

  xassert (valid_image_p (spec));
  bzero (img, sizeof *img);
  img->type = lookup_image_type (image_spec_value (spec, QCtype, NULL));
  xassert (img->type != NULL);
  img->spec = spec;
  img->data.lisp_val = Qnil;
  img->ascent = DEFAULT_IMAGE_ASCENT;
  img->hash = hash;
  return img;

Now, xassert is (in src/dispextern.h):

#define IF_DEBUG(X)     X
#define xassert(X)      do {if (!(X)) abort ();} while (0)
#define IF_DEBUG(X)     (void) 0
#define xassert(X)      (void) 0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]