[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes
From: |
John Bley |
Subject: |
Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes |
Date: |
Sat, 17 Apr 1999 09:11:57 -0400 (EDT) |
On Sat, 17 Apr 1999, Larry W. Virden wrote:
> > Strange:
> > Turning trace off at compile-time transforms all instances of
> > CTRACE(...)
> > to
> > if (0) fprintf(...)
> > But the string literals in the CTRACE calls still wind up in the binaries
> > for me. (Tried this with both Sun's cc and gcc). This is like 30k worth
> > of string literal over the whole lynx source. It's very disturbing.
> Can you change things to say
> #if 0
> fprintf(...)
> instead? That will get rid of the strings you are trying to get rid of.
Not by redefining CTRACE. Here's the basic idea from the code:
#ifdef NO_LYNX_TRACE
#define TRACE 0
#else
#define TRACE some_variable_name_I_forget
#endif
#define CTRACE if(TRACE) fprintf
So that CTRACE(...) becomes
if(TRACE) fprintf (...)
^^^^^ this stuff untouched by the macro expansion
This is really a bizarre hack. I can't redefine CTRACE to be a macro
function:
#define CTRACE(a, b, c) something-or-other /* Can't do this */
because CTRACE passes on a varargs to fprintf, and I don't think you can
reliably do a varargs macro function.
> Of course, IMO once someone has compiled out info like ctrace, it should
> a) no longer be permitted to be called lynx and b) no longer be acceptable
> to send problem reports to the list...
That's why you have to explicitly --disable-trace. I live in a
small-quota world and like saving all the space I can.
--
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