Re: LYNX-DEV fotemods typo & memory leak

[Foteos Macrides]

Klaus Weide <address@hidden> wrote:
>1) GridText.c, near top of HText_beginAnchor:
>
>        j = (text->last_line->size - i);
>        if (LINKS_ARE_NUMBERED &&
>            text->last_line->data[j] == ']' && 1 > 1) {
>            i--;
>            j++;
>        }
>
>I suppose that was meant to be i > 1.

        Ugh, that garbage if(){} clause shouldn't be there at all (just
the  j = ...  line above it), and isn't in my GridText.c here.  It must
have been too late at night and I screwed up when copying modified files
to slcc for zipping.  Sigh...


>2) HTML_start_element, case HTML_IMG:
>
>                if ((temp = HTParse(map_href, me->node_anchor->address,
>                                    PARSE_ALL)) &&
>                    LYHaveImageMap(temp)) {
>                    /*
>                     *  Use reference related to the current stream. - FM
>                     */
>                    StrAllocCopy(map_href, temp);
>                    UseBASE = FALSE;
>                } else {
>                    /*
>                     *  Use reference related to the base. - FM
>                     */
>                    temp = HTParse(map_href, me->base_href, PARSE_ALL);
>                    StrAllocCopy(map_href, temp);
>                    UseBASE = TRUE;
>                }
>                FREE(temp);
> 
>If the first LYHaveImageMap() returns FALSE, temp will be reused
>without first FREEing it.

        Right.
        
        I'll be putting out an update later today or tomorrow, but I
wanted to see the HTML.c stack mods you said were "below" in one of
of your messages, but weren't, and I assumed you'd put them in a
subsequent message.

        Anyway, I don't see how you can deal with the problems
associated with a stack overrun solely in HTML.c.  The SGML.c
stack is a simple, forever-extensible list, so it keeps pushing
beyond 800 and calling HTML_start_element(), which just ignores
the execess.  Then, when the SGML.c stack pops and calls
HTML_end_element(), the requirement of perfect correspondence
betweet the two stacks is violated, and it could crash via the
code for handling cases in HTML_end_element(), or when it uses
the UPDATE_STYLE macro if the style element has garbage or
became an invalid pointer.

        To my knowledge, that businesswire page was the first,
ever in the history of Lynx, to cause a stack overrun, and my
mods deal with that, plus greatly reduce the likelihood of
severely bad HTML causing a stack overrun, so I didn't worry
about the kinds of mods needed to ensure alignment between
the two stacks should an overrun ever occur again.

        But if there's some bad logic within the checks for
an overrun, or pushes and pops within HTML.c, fixes for that
certainly should be included.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;