[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Another proposed patch

From: pg
Subject: Re: lynx-dev Another proposed patch
Date: Sun, 22 Nov 1998 08:38:41 -0700 (MST)

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
     * 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, but I hadn't
the fortitude.

-- gil

reply via email to

[Prev in Thread] Current Thread [Next in Thread]