| > 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
sequence:
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.
Bravo.)
-- 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.
_______________________________________________
