On 6/7/19 11:48 PM, Antonio Scuri wrote:
Hi All,
Here are some comments about the warnings report:
- The report sent by Sur has 4000 lines. I just spent a long time taking a
good look again at it. My opinion does not change.
[...]
Thank you for your effort. IUP is a beast, compared to CD, and, to a lesser
extent IM, in terms of the warnings produced. IM fares badly because, again,
it has a lot of third-party libraries that have were incorporated a long time
ago, and the GCC folks have steadily worked in improving code flow analysis,
and increasing the types, number and accuracy of warnings, over the time
since the initial incorporation.
One of the most verbose warnings is the "misleading indentation" warning for
the various types of control constructs. This warning was added as a result
of a serious security hole in Apple's OS, CVE-20140-1266, a.k.a. "goto fail":
David A Wheeler: "The Apple goto fail vulnerability: lessons learned"
https://dwheeler.com/essays/apple-goto-fail.html
CVE-2014-1266 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1266)
states:
The SSLVerifySignedServerKeyExchange function in
libsecurity_ssl/lib/sslKeyExchange.c in the Secure Transport feature
in the Data Security component in Apple iOS 6.x before 6.1.6 and 7.x
before 7.0.6, Apple TV 6.x before 6.0.2, and Apple OS X 10.9.x before
10.9.2 does not check the signature in a TLS Server Key Exchange
message, which allows man-in-the-middle attackers to spoof SSL
servers by (1) using an arbitrary private key for the signing step
or (2) omitting the signing step.
David Wheeler provides a snippet from SSLVerifySignedServerKeyExchange:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
... other checks ...
fail:
... buffer frees (cleanups) ...
return err;
The misleading indentation here let in a serious security vulnerability
into production releases across a range of products. As suggested in Wheeler's
paper, the "misleading indentation" warning was added as a direct response
to this defect.
Many projects have adopted a zero-tolerance approach to warnings, where,
notably as in this case, if the warning had been implemented prior to the
work on this code, it would have pointed out the defective second
"goto fail;" statement. The compiler community reacted quickly, and added
the "misleading indentation" diagnostic.
Coding standards for many projects, especially safety-critical or very
high-value missions, have adopted a sophisticated nearly-zero-tolerance
to warnings, as follows:
- If the compiler writers chose to implement a warning because of a
reaction to a real-world bug, then the warning is, by default,
seen as a defect unless the developer can make a compelling case,
in a code review, why both of the following is true:
(a) The compiler is erroneous in its analysis; and
(b) It is too hard for the developer to rework the code
to avoid the warning -- perhaps the code can be changed
to appease one compiler, only to have a second compiler
(or perhaps another analysis tool) complain about the
change.
- If the warning is deemed to be truly spurious, then the warning
is suppressed via a "triage" step, before the final warning
report is issued.
- As pointed the warnings in third party libraries will be ignored. I think
Sur could exclude that from the report. Would be easier for me to read.
Especially Scintilla and MathGL that are in C++ generates lots of warnings.
[...]
See Gerard Holzmann's presentation "Mars Code" from Usenix 2012, about how
the software for mission, including the Curiosity rover, (near 4 million
lines of C code, too large to do paragraph-by-paragraph code reviews) was
helped by automated tools, including Coverity and CodeSonar, and compiler
warnings (across multiple compilers, including GCC) to analyse the code,
with nightly full-codebase analysis runs.
In the talk, he mentions first using "-Wall" for GCC, then later tightening
the screws by using "-Wall -Werror", and THEN tightening the screws further
by using "-Wall -Wpedantic -Werror" (with a longish time-frame between each
increase in compiler warning level, so developers can clear the decks and
breathe a sigh of relief, only to suddenly find the "clean" code is again
back under the hammer under the new, tightened regime).
https://www.usenix.org/conference/hotdep12/workshop-program/presentation/Holzmann
I've worked on another project where a build farm subjected the codebase
to a full rebuild, across a variety of machines and architectures (e.g. both
big-endian and little-endian architectures), and with a demand for
zero warnings to be maintained with each code check-in. I found this
environment to be very valuable in helping to produce robust code (for an
application demanding a very, very low defect level).
Okay, enough for this first message. I can see encouraging ways to go
forward from here (especially if I implement a "suppress/triage" database
facility related to "parse-build.lua", and this database can be populated
carefully, trying to choose which warnings are to be suppressed, to
minimise the chances of errors slipping through).
cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
