lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Another proposed patch


From: dickey
Subject: Re: lynx-dev Another proposed patch
Date: Sun, 22 Nov 1998 15:18:17 -0500 (EST)

> In a recent note, address@hidden said: 
>  
> > Date: Sun, 22 Nov 1998 13:38:33 -0500 (EST) 
> >  
> > ok (I don't have a current copy).  What does the page look like when 
> > you have your fix applied?  (I suspect there's a null pointer that 
> > we don't really want). 
> >    
> The problem occurs when configure causes something to be 
> defined as nothing in lynx_cfg.h: 
>  
>     /* #undef _ALL_SOURCE */ 
>     /* #undef const */ 
>     #define inline             /* This is the culprit */  
>     /* #undef mode_t */ 
>     /* #undef off_t */ 
>  
> cfg_defs.sh transforms this to: 

so it's an error in my sed script (it may be simpler to patch the C code
as Larry indicated ;-)

The cases where I'm looking all have an empty string "", rather than the
missing token.
  
>         { "ZCAT_PATH", "/mvsoeecc/tools/bin/zcat" }, 
>         { "ZIP_PATH", "/mvsoeecc/sppg/bin/zip" }, 
>         { "inline" },                                  /* The culprit, again 
> */ 
>         { "lstat", "stat" }, 
> }; 
>  
> Which the compiler evidently interprets as: 

the compiler's right, of course.
  
>         { "ZCAT_PATH", "/mvsoeecc/tools/bin/zcat" }, 
>         { "ZIP_PATH", "/mvsoeecc/sppg/bin/zip" }, 
>         { "inline", NULL  },                           /* The culprit, again 
> */ 
>         { "lstat", "stat" }, 
> }; 
> and LYShowInfo gets a SIGSEGV on the NULL and the page 
> never gets built. 
>  
> Larry's patch and mine both supply a default value instead of 
> the NULL at execution time.  It would generate a slightly 
> smaller executable if this were done in cfg_defs.sh, but I 
> was daunted by the sed script. 

The sed script is about as complicated as it'll get - we're running into
portability constraints.  I'll look into fixing both - but for 2.8.1 fixes,
the C code is a more stable place to fix it.
  
> -- gil 


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

reply via email to

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