Sean,

I think you would want to provide this guarantee through some sort of static 
assertion.  For example, if you want to ensure that text controlled by FRED is 
not included in a release build, you could include an #error preprocessor 
directive as part of the controlled text that will generate an error message 
for a release build:

#ifdef FRED
#  define MACRO(x) (x + 5)
#  ifdef NDEBUG
#     error "FRED defined in release build"
#  endif
#endif

The idea here is that NDEBUG would be defined for a release build. If FRED and 
NDEBUG were defined in the same build it would result in a fatal compile-time 
diagnostic.

I'm not sure if there is a more elegant or widely deployed solution to this 
problem.

rCs

-----Original Message-----
From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
Behalf Of smurray1
Sent: Friday, February 13, 2009 10:49 AM
To: sc-l@securecoding.org
Subject: [SC-L] Conditional Compile statements-- coding standards, and code 
review

I am reviewing a QA team's procedures for code review.  I have an issue with 
conditional compile statements (#ifdef in the C world).  My issue is that it is 
very difficult to have complete confidence that a piece of code inside the 
condition (the "controlled text") does indeed not get compiled and included in 
the final executable.  The coding standards used by the organization are fairly 
rigorous, but there is no mention of prohibiting (or of even limiting) the used 
of conditional compile statements.  They are typically used for debug 
purposes-- that is, debug messages that get generated when the code is compiled 
for debugging and then are omitted in the production builds.  This is probably 
more of a correct code issue than a security issue,  but there are most 
definitely security implications. 

I am curious to hear people's thoughts on this.  Do most organizations prohibit 
(or at least limit) conditional compile statements?  If not, how is the 
"controlled text" inside conditional compile statements handled by code 
reviewers?  The QA procedures I am reviewing basically ignore them, since "They 
won't be in the production build", but I am 
very uncomfortable with that.   There are many ways in C to define the 
macro that controls the conditional compile (with #define statements, with 
compiler flags, etc).  It just seems very hard to verify that the ifdefs will 
work as planned in the final compile.

Thanks!!

Sean T Murray
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, 
subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a 
free, non-commercial service to the software security community.
_______________________________________________

_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________

Reply via email to