lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev The whole CTRACE thing


From: dickey
Subject: Re: lynx-dev The whole CTRACE thing
Date: Mon, 19 Apr 1999 06:38:12 -0400 (EDT)

> 
> Again, not advocating doing anything drastic for 2.8.2, but I do think  
> CTRACE needs to be replaced eventually.  Here's why: 

yes (eventually).

I'm aware of this (bear in mind that before the 2.8.2 development, we had
no working varargs - someone broke lynx's includes for that to workaround a
bug in slang).

Doing CTRACE the 'right' way would be easiest by cloning the
HTSprint/HTSprintf0 varargs processing (or restructuring a little to pass a
va_list pointer to common code).  I'm more interested in making HTSprintf,
etc., well tested in the context of buffer overflow though, than in
refining a second-order problem.
 
>   CTRACE(...); 
>   if (TRACE) fprintf(...); 
>                     ^^^^^^ literal text from the original line 
>  
> So what happens with this? 
>   if (warning_cond)    /* Note lack of {}s */ 
>       CTRACE(... "Warning: blah blah"); 
>   else 
>      do_safe_stuff(); 
>  
> becomes (to the compiler): 
>  
>   if(warning_cond) 
>       if (TRACE) fprintf(... "Warning: blah blah"); 
>       else /* bound to the if (TRACE), not the if (warning_cond) */ 
>          do_safe_stuff(); 
>  
> Now, I don't think this has happened in the lynx source as far as I can see. 
> People have been careful to wrap if/elses using CTRACE with {}s. 
> That doesn't mean it isn't an accident waiting to happen. 
>  
> --  
> John Bley - address@hidden 
> Duke '99 - English/Computer Science 
>   Since English is a mess, it maps well onto the problem space, 
>   which is also a mess, which we call reality.     - Larry Wall 


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

reply via email to

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