LYNX-DEV color style code, LWV's dbx results

[Klaus Weide]

On Thu, 16 Oct 1997, Larry W. Virden, x2487 wrote:
...
> Anyways, the reason I connect the problem with color style is that only
> if the color style sheet file is in place, and the program is configured
> for color styles, do I see the problem.

Anything you discover now with dbx etc. may not be connected to the style
code.  Hopefully.  SO check those assumptions.

> >> lynx compiles just fine.
> >> 
> >> I then start up dbx and tell it to do memory checking.
> >
> >What's the invocation for that?   (just curious)
> 
> In Sun's dbx, the new subcommand is 
> 
> check -all
> 
> The help for check mentions a -frame <n> and -match <m> but I have
> no idea what purpose they serve.
> 
> > Change the last part of function Cleanse so that it becomes:
> 
>  [code snipped]
> > Does that solve it?  Next problem from your stress-testing? :)
> 
> Well, it doesn't solve all the problems - the color-style enabled code
> still doesn't do the status line correctly if no style sheet is present
> (for instance, right now it says:
> 
> -more- 
> http://homepage/projects/source/usenet/rasters/B5/Calendars/
> 
> However, _with_ a style sheet in place, things now appear to be working!

As far as I know, nobody has ever given the impression that the color 
style code _is supposed to work_ without a .lss file -- not Rob, not me,
not Tom.  It's a miracle it works at all!

> I checked the trace file and all those x'FF' characters are gone.

I hope the color style code doesn't cause memory corruption any more.
I had thought so before, so I may well be wrong again.  It may still occur
in obscure cases for all I know.

> Now we just need to fix up the case where no style sheet is present.

Well "we" don't have to do that, IMHO.  If you, or other users of the
color style code, want to do it and contribute the changes, fine.

There is a `char* default_stylesheet[]' defined in LYStyle.c with strings
that have the same syntax as what's in the .lss file.  You may be able to
put stuff there for which you think a .lss file shouldn't be needed.
Have you tried what I suggested, a .lss file with just two entries for
"status" and "alert"?

The style code specific handling of the statusline is in LYUtils.c, at the
end of the function (how original!) statusline.  Maybe that needs tweaks
or clenup, or even should go away.

I think I have given enough hints so that those who really want to
marginally improve the color style code can know where to start
experimenting.  If nobody does that, then - as far as I am concerned -
the "unsupported" color style code in the code set will probably stay as
it is.

The following is a different topic:


> Read from uninitialized (rui): Attempting to read 1 byte at address 0x56e431
> which is 225 bytes into a heap block of size 1024 bytes at 0x56e350
> This block was allocated from:
> [1] HTLoadHTTP() at line 656 in "HTTP.c"
...
> Current function is HTLoadHTTP
> 732               memcpy(line_kept_clean, line_buffer, buffer_length);
> (dbx 4) where     
>   [1] memcpy(0x56e768, 0x56e350, 0x400, 0x400, 0xef79a618, 0x0), at 0xef777fb0
> =>[2] HTLoadHTTP(arg = 0x5600f0 
> "http://homepage/home/lwv26/.parms/home.html";, anAnchor = 0x565dc0, 
> format_out = 0x55c520, sink = (nil)), line 732 in "HTTP.c"
>   [3] HTLoad(addr = 0x57cb48 "http://homepage/home/lwv26/.parms/home.html";, 
> anchor = 0x565dc0, format_out = 0x55c520, sink = (nil)), line 560 in 
> "HTAccess.c"
>   [4] HTLoadDocument(full_address = 0x57cb48 
> "http://homepage/home/lwv26/.parms/home.html";, anchor = 0x565dc0, format_out 
> = 0x55c520, sink = (nil)), line 736 in "HTAccess.c">   [5] 
> HTLoadAbsolute(docaddr = 0xefffd6e4), line 914 in "HTAccess.c"
... 
> Does any of this help?

dbx is being too picky here, or rather it cannot know that what it detects
doesn't cause any problems. (It is only a stupid computer program after
all.)  Lynx is copying a buffer of memory, some of which may be
uninitialized, but that doesn't matter since Lynx won't later acces the
uninitialized portion of it.

Ignore this warning (and possibly other "rui" warnings) and proceed.
Or replace in HTTP.c
    line_buffer = (char *) malloc(buffer_length * sizeof(char));
with
    line_buffer = (char *) calloc(buffer_length, sizeof(char));
and
            line_kept_clean = (char *)malloc (buffer_length * sizeof (char));
(immediately preceding the memcpy) with
            line_kept_clean = (char *)calloc (buffer_length, sizeof (char));
and then it shouldn't occur (except possibly in unusual circumstances when
the realloc comes into play).

    Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;