Re: lynx-dev Re: LYNX-DEV lynx_w32.zip feedback

[T.E.Dickey]

> > > > (yes, I'm aware that it would run about 1% slower if we pass all of 
> > > > that  
> > > > stuff on the stack - but it would be much simpler to maintain).  
> > >   
> Yay!  This needs to be done.  I gagged when I saw in LYMain.C: 
  
>         *stderr = *LYTraceLogFP; 
>  
> -- I wondered, "Are you supposed to be able to do that?"  The answer 
> is, "No.  See ANSI C, Sect. 4.9.3 Files": 
>  
>     [ ... ] 
>         The address of the FILE object used to control a stream may be 
>     significant; a copy of the FILE object may not necessarily serve in 
>     place of the original. 
it is rather ugly (but only ten years ago when C was standardized, most
stdio implementations afaik still used an array for the FILE pointers - so
I'd assume this looked like a viable solution because it hadn't been well
tested on more than 2-3 platforms.
  
> > We could work around that by making the macro have the if statement 
> > the way it does now: 
> >     #define DPRINTF(p) if (TRACE) dprintf p 
> >  
> Or, should it be: 
>  
> >       #define DPRINTF(p) { if (TRACE) dprintf p; } 
>  
> to avoid dangling-else problems?  The syntax of C leaves no proper way 
> to do this. 
well, if I put the if inside the function we don't have to worry about
the compilers that don't like the curly braces either.
  
> <make_finger_down_throat_gesture> 
> > to make it reliable as well, we'd probably do what I've seen in other 
> > places 
> > (close & reopen the file after each message). 
> >  
> </make_finger_down_throat_gesture> 
> -- but that could also be made optional with a macro. 
it certainly could (I wouldn't want to do it on a system that works properly).

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