Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [PATCH] Don't compile non-OPENSSL code when using OPENSSL andvice versa
From: Andreas Ericsson <ae () op5 se>
Date: Tue, 28 Feb 2006 21:10:40 +0100

Kris Katterjohn wrote:
From: Andreas Ericsson
Sent: 2/28/2006 1:53:46 AM

I'd be surprised if this actually makes the binary smaller. Any sane 
compiler recognizes and removes dead code when it's as obvious as this 
(most do when it's less obvious). In fact, even code like

#define HAVE_OPENSSL 0

if (HAVE_OPENSSL && some_other_condition)
     do_fun_things();

would be left out entirely. If do_fun_things() is static and called only 
from that point (or within blocks like this), it too will be removed.


While that's most likely very true, is there a reason to make the compiler do it
(just because it should) instead of the preprocessor (because you tell it)?

I'm not by any means saying you're wrong, but I do (at least) think using the
preprocessor #if/#else makes the code more readable/easier to understand rather
than just leaving it out there for the compiler to do.


Perhaps, but considering that of the four patched blocks two were 
"return within ifdef" and two others just moved the #ifdef to above a 
comment, the patch is a no-op for the compiled code with the exception 
of moving that 'int tmp' outside it.

I was just commenting since you didn't seem to be aware of it (no 
comments in the patch message about readability).

Of course, whatever's best.


Naturally. I'd say that 'int tmp' swings the balance. I'd probably apply 
it, after removing the blocks moving the #ifdefs anyways.

-- 
Andreas Ericsson                   andreas.ericsson () op5 se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]