lynx-dev
[Top][All Lists]
Advanced

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

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


From: Klaus Weide
Subject: Re: lynx-dev [PATCH][dev22] Fix --disable-trace, #includes
Date: Sun, 18 Apr 1999 09:21:14 -0500 (CDT)

On Sat, 17 Apr 1999, John Bley wrote:

> On Sat, 17 Apr 1999, Klaus Weide wrote:
> 
> > > * Fix --disable-trace, chop more unneeded #includes (John Bley)
> > Could you explain why --disable-trace needed fixing?  It seems to
> > me you change doesn't really change anything - you now just test
> > for NO_LYNX_TRACE directly rather than indirectly (through DEBUG),
> > or am I missing something?
> 
> Yes, that's what I thought too, but for some reason 
>   ./configure --disable-trace && make all
> was still producing a binary that could do tracing.  (I.e., produces 
> Lynx.trace and fills it with junk).  I tried with both gcc and Sun's cc.
> I don't claim to fully understand why this particular fix works for me, 
> but now when I disable-trace I really don't produce the trace.

There must have been a -DDEBUG somewhere or a '#define DEBUG' in some
unexepected .h file...

> > > Strange:
> > > Turning trace off at compile-time transforms all instances of
> > > CTRACE(...)
> > >   to 
> > > if (0) fprintf(...)
> > 
> > Are you really compiling with -O[>=2] and without -g?
> 
> For gcc, yes.  Also the appropriate flags for cc.  It is quite strange.

I did a very small test (gcc Debian GNU/Linux package 2.7.2.3-7) with:

     #include <stdio.h>
     int main(int argc, char **argv)
     {
         if (0) fprintf(stderr, "%s", "foo bar\n");
         return 0;
     }

No matter what different gcc flags I tried, the string "foo bar" was
still in the binary (as shown by 'string')...  Aparently gcc
optimization is much stupider in this respect than what I would have
expected.  I guess that all constant strings are handled very early in
the compilation process, and then never checked whether actually
referenced after subsequent optimization passes.

I don't think all compilers act like that - IIRC Jim Spath reported
significan size decrease a while ago.

   Klaus


reply via email to

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