Re: lynx-dev Another proposed patch

[pg]

In a recent note, address@hidden said:

> Date: Sun, 22 Nov 1998 07:40:01 -0500 (EST)
> 
> > This one is more serious - it is an attempt to fix a crash.  However, I 
> > am uncertain of the ramifications of the particular strings I have chosen. 
> > The problem is that in certain cases, the address was null, so the fprintf 
> > was crashing. 
> 
I reported this phenomenon and proposed a comparable patch in:

   Linkname: lynx-dev Safety Belt
        URL: http://www.flora.org/lynx-dev/html/month1198/msg00435.html
 
     * Subject: lynx-dev Safety Belt
     * From: address@hidden
     * Date: Tue, 17 Nov 1998 15:32:55 -0700 (MST)

     A few weeks ago, I carelessly defined a null macro in
     config.hin.  This percolated into lynx_cfg.h, thence into
     cfg_defs.h, where it had been transformed into a VOID member
     in a struct initializer.  It took me several hours to track
     down the SIGSEGV every time I pressed "=".  Today, I did it
     again, but it took me less than an hour to recall what had
     happened the last time.

> I agree that it's a potential hole: but which configuration does this?

Will "configure", operating properly, ever generate a null macro
definition, such as:

    #define inline

in a configuration that doesn't support "inline"?

> Perhaps the problem is upstream, and we should not have a null pointer
> in the first place.  I'd like to know - so we can see if this should be
> applied to the 2.8.1 bugfixes.
> 
It might better be fixed upstream in cfg_defs.sh, but I hadn't
the fortitude.

-- gil