Problem report #88

Problem report #88

[Dan Nicolaescu]

This one is similar to #87


CID: 88
Checker: FORWARD_NULL (help)
File: base/src/emacs/src/xfaces.c
Function: Fdisplay_supports_face_attributes_p
Description: Variable "def_face" tracked as NULL was passed to a
function that dereferences it.

6169 	DEFUN ("display-supports-face-attributes-p",
6170 	       Fdisplay_supports_face_attributes_p, Sdisplay_supports_face_attributes_p,
6171 	       1, 2, 0,
6172 	       doc: /* Return non-nil if all the face attributes in ATTRIBUTES are supported.
6173 	The optional argument DISPLAY can be a display name, a frame, or
6174 	nil (meaning the selected frame's display).
6175 	
6176 	The definition of `supported' is somewhat heuristic, but basically means
6177 	that a face containing all the attributes in ATTRIBUTES, when merged
6178 	with the default face for display, can be represented in a way that's
6179 	
6180 	 \(1) different in appearance than the default face, and
6181 	 \(2) `close in spirit' to what the attributes specify, if not exact.
6182 	
6183 	Point (2) implies that a `:weight black' attribute will be satisfied by
6184 	any display that can display bold, and a `:foreground \"yellow\"' as long
6185 	as it can display a yellowish color, but `:slant italic' will _not_ be
6186 	satisfied by the tty display code's automatic substitution of a `dim'
6187 	face for italic.  */)
6188 	  (attributes, display)
6189 	     Lisp_Object attributes, display;
6190 	{
6191 	  int supports, i;
6192 	  Lisp_Object frame;
6193 	  struct frame *f;
6194 	  struct face *def_face;
6195 	  Lisp_Object attrs[LFACE_VECTOR_SIZE];
6196 	
6197 	  if (noninteractive || !initialized)
6198 	    /* We may not be able to access low-level face information in batch
6199 	       mode, or before being dumped, and this function is not going to
6200 	       be very useful in those cases anyway, so just give up.  */
6201 	    return Qnil;
6202 	
6203 	  if (NILP (display))
6204 	    frame = selected_frame;
6205 	  else if (FRAMEP (display))
6206 	    frame = display;
6207 	  else
6208 	    {
6209 	      /* Find any frame on DISPLAY.  */
6210 	      Lisp_Object fl_tail;
6211 	
6212 	      frame = Qnil;
6213 	      for (fl_tail = Vframe_list; CONSP (fl_tail); fl_tail = XCDR (fl_tail))
6214 		{
6215 		  frame = XCAR (fl_tail);
6216 		  if (!NILP (Fequal (Fcdr (Fassq (Qdisplay,
6217 						  XFRAME (frame)->param_alist)),
6218 				     display)))
6219 		    break;
6220 		}
6221 	    }
6222 	
6223 	  CHECK_LIVE_FRAME (frame);
6224 	  f = XFRAME (frame);
6225 	
6226 	  for (i = 0; i < LFACE_VECTOR_SIZE; i++)
6227 	    attrs[i] = Qunspecified;
6228 	  merge_face_ref (f, attributes, attrs, 1, 0);
6229 	
6230 	  def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID);

Event var_compare_op: Added "def_face" due to comparison "def_face == 0"
Also see events: [var_deref_model]
At conditional (1): "def_face == 0" taking true path

6231 	  if (def_face == NULL)
6232 	    {

At conditional (2): "realize_basic_faces == 0" taking false path

6233 	      if (! realize_basic_faces (f))
6234 		error ("Cannot realize default face");

At conditional (3): "0 < ((f)->face_cache)->used" taking false path

6235 	      def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID);
6236 	    }
6237 	
6238 	  /* Dispatch to the appropriate handler.  */

At conditional (4): "(f)->output_method == 0" taking false path
At conditional (5): "(f)->output_method == 2" taking false path

6239 	  if (FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))
6240 	    supports = tty_supports_face_attributes_p (f, attrs, def_face);
6241 	#ifdef HAVE_WINDOW_SYSTEM
6242 	  else

Event var_deref_model: Variable "def_face" tracked as NULL was passed to a function that dereferences it. [model]
Also see events: [var_compare_op]

6243 	    supports = x_supports_face_attributes_p (f, attrs, def_face);
6244 	#endif
6245 	
6246 	  return supports ? Qt : Qnil;
6247 	}

Re: Problem report #88

[Richard Stallman]

I think this is safe, because it is impossible for 
FACE_FROM_ID (f, DEFAULT_FACE_ID) to be null
after realize_basic_faces succeeds.

Likewise, #87 is not a real problem.

I will add an assertion to make these reports go away.