Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes

[John Bley]

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