Re: lynx-dev [patch] 2.8.3dev.16 - cookie_save_file [2nd patch]

[Klaus Weide]

On Sun, 19 Dec 1999, brian j pardy wrote:
> On Sat, Dec 18, 1999, brian j pardy wrote:
> > 
> > I'll see if I can come up with anything in getfile() to figure out if
> > it was indeed a successful -source (etc) operation.
> 
> My second attempt.  The -source segfault with the earlier patch was
> due to the call to HTFindPoundSelector() -- the anchor elements aren't
> populated in dump_output_immediately mode.

Not strictly true; with -dump (but not -source), HTMainText and its
node_anchor are there.  But even in that case calling
HTFindPoundSelector() is pointless (although it should not crash),
the result will never be used.  So HTFindPoundSelector can just
be skipped for dump_output_immediately, as you do.

>  I'm short-circuiting the
> check on HTLoadedDocumentURL() when in d_o_i mode -- getfile() will
> then return NORMAL, and it looks like the rest of the code can handle
> it properly, apart from HTFindPoundSelector().
> 
> Any thoughts here?

> diff -ru 2.8.3dev.17/src/LYGetFile.c 2.8.3dev.17.bri/src/LYGetFile.c
> --- 2.8.3dev.17/src/LYGetFile.c       Wed Dec 15 18:22:16 1999
> +++ 2.8.3dev.17.bri/src/LYGetFile.c   Sun Dec 19 02:19:49 1999
> @@ -1042,8 +1042,14 @@
>                                   *  anchor deletion problems), so this
>                                   *  is too. - FM
>                                   */
> -                                (strcmp(doc->address,
> -                                        HTLoadedDocumentURL()) ||
> +
> +                                /*
> +                                 * Allow in non-interactive mode. - BJP
> +                                 */
> +                                ((strcmp(doc->address,
> +                                        HTLoadedDocumentURL()) &&
> +                                 !dump_output_immediately) ||

You are effectively disabling the doc->address test here for d_o_i,
but you are still leaving the doc->post_data and doc->isHEAD in.
So it seems getfile() can still sometimes return(NULLFILE) when it
shouldn't, with something like 'lynx -source -post_data' or
'lynx -head -source'.

Actually, I think it requires less tweaking *and* would be more
obvious to make the short-circuit shorter...  basically, a

     if (dump_output_immediately)
          return(NORMAL);

in the right place, before any of the pound and HTLoadedDocument...
checks (but after we know HTLoadAbsolute was successful, of course).

Maybe before this

                        } else if (pound == NULL &&

or even before this:
                    /*
                     *  Some URL's don't actually return a document;
                     *  compare doc->address with the document that is
(since there should never be a WWW_Download_File for d_o_i...)

Well, to be sure to not change the flow of control for cases we're not
interested in changing (-dump without -source), I'd probably change the
short-circuit return to

     if (dump_output_immediately && !HTMainText)
          return(NORMAL);

or similar.  This would let -dump continue to go through the
HTLoadedDoc...  comparisons, leaving that code a chance to return NULLFILE
instead of NORMAL if "something doesn't match" (not sure in what
situation that actually occurs).
Should directly accessing HTMainText be avoided? In that case 
the following would be equivalent:

     if (dump_output_immediately && !strcmp(HTLoadedDocumentURL(), ""))
          return(NORMAL);

...

But there are still posssible cases where -source or similar does
not go through that main loading path
                    if (!HTLoadAbsolute(&WWWDoc)) {
                        /*
                         *  Check for redirection.
                         */

at all... Obscure invocations like
     lynx {-source,-dump} {LYNXOPTIONS:,LYNXCFG:,LYNXCOMPILEOPTS:}

work now (even LYNXCFG://reload, it seems).  They should probably
be checked so they continue to work like now (without an error
message), or at least should not be broken "accidentally".


  Klaus