Well, no-window-name/no-icon-name/no-class patch which is applied to
pl34 is too buggy (I think this code is not tested:), and should go away
(But, I do not think this patch's policy is bad).
chuck_hines> pl 36 to 37
chuck_hines> 1. Fixed coredump due to incomplete backout of NoName/NoClass patch
I doubt this fixes is done:)
In HandlePropertyNotify(), code says:
if (!XGetWMName(dpy, Tmp_win->w, &text_prop))
return;
free_window_names (Tmp_win, True, False);
Tmp_win->name = (char *)text_prop.value;
In fact, XGetWMName() simply calls XGetTextProperty. Let us see
XGetTextProperty(3X) manuals.
If the specified property does not exist on the window,
XGetTextProperty sets the value field to NULL,...
So, text_prop.value may be NULL. In old ways, If property is NULL,
property turns to be NoName (yes, this is the internal constant value).
But now, it seems that fvwm allows to set Tmp_win->name to NULL. I
think this is the policy change of fvwm, and that's o.k.
But, free_window_names() does not consider this fact. see misc.c:
if (tmp->name != tmp->icon_name && tmp->name != NoName)
XFree (tmp->name);
tmp->name = NULL;
WOW! we are going to XFree(NULL) :-)
I hope fvwm's iconname/windowname handling is fixed before 2.1 release.
***
If you, all the patch maker, want to release patch, please check your
code does not have a bug, or say "I have not tested" :-)
- -
Makoto 'MAR_kun' MATSUSHITA
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Tue Oct 10 1995 - 09:07:32 BST