[Emacs-bug-tracker] bug#6855: closed (24.0.50; Bug in tool bar label handling)

[GNU bug Tracking System]

Your message dated Sun, 15 Aug 2010 10:20:05 +0200
with message-id <address@hidden>
and subject line Re: bug#6855: 24.0.50; Bug in tool bar label handling
has caused the GNU bug report #6855,
regarding 24.0.50; Bug in tool bar label handling
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
6855: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6855
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> 24.0.50; Bug in tool bar label handling
>
>
>
>
> Date: 
>
> Sat, 14 Aug 2010 14:04:25 +0200
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
>
>
>
>
> There are some bugs in the handling of tool bar labels that can cause
> Emacs to crash.
>
>
>
> ### gtkutil.c: update_frame_tool_bar ###
>
>     char *label = SSDATA (PROP (TOOL_BAR_ITEM_LABEL));
>
> Here we take string data out.
>
>
>
> ### keyboard.c: parse_tool_bar_item ###
>
>       else if (EQ (key, QClabel))
>         {
>           /* `:label LABEL-STRING'.  */
>           PROP (TOOL_BAR_ITEM_LABEL) = value;
>           have_label = 1;
>         }
>
> But here we put an arbitrary object in.
>
>
> ...
>
>   if (!have_label)
>
> ...
>       char buf[64];
>       EMACS_INT max_lbl = 2*tool_bar_max_label_size;
>       Lisp_Object new_lbl;
>
>       if (strlen (caption) < max_lbl && caption[0] != '\0')
>         {
>           strcpy (buf, caption);
>
> tool-bar-max-label-size is a user variable, so this can mean a buffer
> overflow.
>
>
> ...
>       if (SCHARS (new_lbl) <= tool_bar_max_label_size)
>         PROP (TOOL_BAR_ITEM_LABEL) = new_lbl;
>
> If we came here but the branch is not taken, the label will be nil,
> not a string.
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#6855: 24.0.50; Bug in tool bar label handling
>
>
>
>
> Date: 
>
> Sun, 15 Aug 2010 10:20:05 +0200
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE;	rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
>
>
>
>
>
> Johan Bockgård skrev 2010-08-14 14.04:
> > There are some bugs in the handling of tool bar labels that can cause
> > Emacs to crash.
> >
> >
> >
> > ### gtkutil.c: update_frame_tool_bar ###
> >
> >      char *label = SSDATA (PROP (TOOL_BAR_ITEM_LABEL));
> >
> > Here we take string data out.
> >
> >
> >
> > ### keyboard.c: parse_tool_bar_item ###
> >
> >        else if (EQ (key, QClabel))
> >          {
> >            /* `:label LABEL-STRING'.  */
> >            PROP (TOOL_BAR_ITEM_LABEL) = value;
> >            have_label = 1;
> >          }
> >
> > But here we put an arbitrary object in.
>
> We kind of assume people do the sensible thing and put in strings.  It is the
> same as for help and image.  If Emacs crashes because somebody didn't put
> in a string, that is actually a good thing IMHO.  The error becomes very
> apparent then.
>
> > ...
> >
> >    if (!have_label)
> >
> > ...
> >        char buf[64];
> >        EMACS_INT max_lbl = 2*tool_bar_max_label_size;
> >        Lisp_Object new_lbl;
> >
> >        if (strlen (caption)<  max_lbl&&  caption[0] != '\0')
> >          {
> >            strcpy (buf, caption);
> >
> > tool-bar-max-label-size is a user variable, so this can mean a buffer
> > overflow.
> >
> >
> > ...
> >        if (SCHARS (new_lbl)<= tool_bar_max_label_size)
> >          PROP (TOOL_BAR_ITEM_LABEL) = new_lbl;
> >
> > If we came here but the branch is not taken, the label will be nil,
> > not a string.
>
> I have checked in a fix for those two.
>
> Thanks,
>
>         Jan D.
>
>
>
>
>
> --- End Message ---