|  > are shops that insist on warning free compiles really that rare?
| Yes.  I've worked for or with many companies over the years, totalling 
| probably somewhere in the mid-teens or so.  In all that, there was, to the 
| best of my recollection, only ONE that insisted on it, other than my own 
| "one man show".  Add to that, numerous open source apps I've compiled; I 
| haven't kept track of how many were warning-free, but it's rare enough that 
| I consider it a pleasant surprise.
| In several projects, I fixed some nasty bugs (inherited from other people) 
| by turning warnings on (they were often totally suppressed!), and fixing the 
| things that the warnings were trying to warn me about.  This is of course 
| obvious to you and me, and probably to most of this list, but apparently not 
| to the vast majority of programmers (even so-called software engineers), let 
| alone people in any position of authority to set such policies.  :-(
I have no idea how common it actually is, but based on my own experience -
where I required it from my guys and we enforced it on software written
by others - it's not very common.  Unless you push  for it, very few
programmers will even think about it.  (In fact, unless you're in a
position to control the compiler options - I was - most programmers
will set them to just shut the damn compiler up.)

A couple of issues are relevant here, however:

        - The level of warnings available in compilers varies, and
                some of the warnings are ... dumb.  We built on
                maybe 5 different compilers, and you could easily
                find examples where only one compiler would warn on
                something.  On the other hand, you ran into things
                like Microsoft compilers that warned about "u == 1"
                when u was unsigned, or compilers that got confused
                about control flow and warned about unreachable code
                that wasn't, or alternatively about loops with no
                exits (which had them).  These are allo annoyances
                one can work around with sufficient will, but you
                have to *want* to.

        - If you're not *really* careful in teaching people about
                how to fix warnings, they will hide them.  In C
                and C++, all too many warnings get hidden by a
                cast here and there.  (I always quote Henry Spencer's
                classic comment:  If you lie to the compiler it
                will get its revenge.)  A more subtle problem I've
                seen is "fixing" a warning tht some variable isn't
                initialized along some path by simply setting it
                to some arbitrary value - almost always 0, actually -
                in its declaration.  This one is particularly bad
                because many style guides recommend that you always
                initialize every value on declaration.  (Note that
                in C++, everything but the basic types inherited
                from C is always initialized - even if to a value
                that may be meaningless in context.  As a result,
                you lose a valuable potential warning.  The advice
                that you never declare a variable until you know
                what to initialize it to fails in the common code

                T v;
                if (condition)
                        v = f1();
                else    v = f2();

                where both f1() and f2() are expensive, so you can't
                make either the default.

                This isn't a C++ issue, BTW - safe languages generally
                require that a variable *always* receive some valid
                value.  (Java does do a lot of work to recover the
                notion of a variable being "undefined" before its use.

                                                        -- Jerry

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