Re: LYNX-DEV weird crashes

[Foteos Macrides]

Klaus Weide <address@hidden> wrote:
>>[...]
>> that had no VALUE="foo" attribute, and thus had it set to a
>> zero-length string, which was still valid, too, in the obsolete
>> links[i].forms->value element of the obsolute links[i].forms
>> structure.  So what's the right way to interpret those dbx
>> outputs?
>
>That 0xa is taken (by LYno_attr_char_case_strstr) to be a (char *),
>i.e. a memory address.  It's an invalid one, because the space once
>occupied by the FormInfo structure is now used for something else.
>dbx appears to try to interpret it as a string, but that can only
>give random garbage - for example "" if the byte stored at 0x0000000a
>happens to be 0x00.
>
>Well that's my explanation...

        Well, OK, but on VMS if it had been recovered by the system,
it would crash when you checked whether it was NULL (in effect, has
value 0x00), so you'd be dead before the LYno_attr_char_case_strstr()
call.  That's why I was asking whether on Unix you can check values
outside your current process-allocated memory space and not crash
(there may other bad logic in Lynx, if so).  Whereas if it *is* in
your current process-allocated memory space, and it's value is 0x00,
then it's a zero-length string, functionally.  Could this be related
to some Unix compilers defining NULL as simply 0, without casting it
to a pointer?

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