lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV Lynx32 blows up when reading >64k


From: Foteos Macrides
Subject: Re: LYNX-DEV Lynx32 blows up when reading >64k
Date: Mon, 14 Apr 1997 18:04:16 -0500 (EST)

Wayne Buttles <address@hidden> wrote:
>On Mon, 14 Apr 1997, Foteos Macrides wrote:
>
>> Wayne Buttles <address@hidden> wrote:
>> >> HTML: ****** Maximum nesting of 800 tags exceeded!
>> >
>> >I suppose we could up the limit, but how high?
>> 
>>      Why not instead heed the bad HTML statusline message which
>> precedes the stack overrun, and suggest that something be done
>> about all those invalidly unclosed Anchors? 
>
>If you mean ask the author to fix the page, I believe this one is beyond
>hope.  Netscape's own website has many pages without closing name tags so
>you can't expect a browser-X supporter to cater to valid HTML.  
>
>I am not prepared to fix the problem in lynx, that is why I commented the
>way I did.  As far as a fix goes, since tags are not nestable AFAIK we
>should be closing the last one as we get a new one. 

        If you can't induce the document provider to fix that HTML, then
conceptualizing it as a need to "fix the problem in lynx" won't get you
any further.  Arbitrarily increasing the size of the stack or making it
dynamic won't get the anchors handled properly.  You can check for
whether me->inA is TRUE under case HTML_A: in HTML_start_element(), and
if so call HTML_end_element() to close it before starting the next
anchor, and add precautionary checks in HTML_end_element() to not pop
the stack and not invoke the close anchor code if it's called to close
an anchor when me->inA is FALSE.  That will get the document rendered
without a stack overflow, and get the anchors with HREFs registered as
links which can be activated, but their link names will not all be
what's indended, particularly in conjunction with other bad HTML in
that document.

        If you're talking about rewriting Lynx to emulate Netscape's
non-HTML parsing behavior, that's not the same as porting Lynx to
another platform under circumstance were you have the source code.
Nobody, in fact, is going to rewrite Lynx based on trial and error
experimentation with Netscape to guess what it's actually does,
which can change from one version of Netscape to the next.

        If you're talking about rewriting Lynx in conformance with
what specs Netscape offers, that won't help either because Netscape
doesn't actually conform to them.

        Some thing just fall in the category of wishful thinking,
and discussions about them might just as well be about fitting more
angels on the head of a pin.  Sigh...

        Lot's of worthwhile things still CAN be done with Lynx,
if realistic objectives are set.

                                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.
;

reply via email to

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