[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