Re: lynx-dev Another proposed patch

[dickey]

> 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: 
  
I read this - but did not understand the problem you were reporting (sorry).

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


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey