<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body text="#000000" bgcolor="#ffffff">
I have a friend trying to sell software that uses static<br>
analysis to detect bugs. It's for Ada, which is often<br>
used for mission-critical software, and for Java.<br>
(It's called SofCheck, by Tucker Taft, one of the world's<br>
experts in highly-optimizing compilers.)<br>
<br>
His main problem selling it is that potential<br>
customers simply don't care about bugs! They say<br>
"Oh, if there's a bug that matters, then some<br>
user will report it and we'll fix it." I was<br>
amazed by this; if his tool worked for Common Lisp<br>
I would love it and I think my team would happily<br>
embrace it.<br>
<br>
The weak part of all such tools is that there<br>
are always false positives and false negatives.<br>
You can read about the "findbugs" tool and<br>
how they have dealt with this. SofCheck is<br>
a far more powerful tool than findbugs but<br>
in the same genre.<br>
<br>
Some of his competitors sell similar technology,<br>
billing it as a security product rather than<br>
a bug product. My friend has ethical qualms<br>
about this; he's not so sure that it's fair to<br>
describe the software that way, as compared<br>
to software that has been explicitly designed<br>
to find the usual sources of security holes<br>
such as buffer overflows and SQL injection<br>
and so on.<br>
<br>
-- Dan<br>
<br>
Robert P. Goldman wrote:
<blockquote type="cite" cite="mid:E0E5697E-4D4C-4A7B-B1C1-9561A7414596@sift.info">
<pre wrap="">Not only that, but if you are slow to market, your company dies.
I was peripherally involved with some people trying to do high reliability os development for avionics, and as far as I can tell no one wants to pay what this kind of software engineering really costs. Not even in industries that are safety critical.
On Feb 23, 2011, at 23:56, Ron Garret <a href="mailto:ron@flownet.com" class="moz-txt-link-rfc2396E"><ron@flownet.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The problem is that the market for operating systems is very different than the market for bridges. Notwithstanding the odd comp.risks horror story, in general when an OS leaks resources people may be inconvenienced, but they don't die.
On Feb 23, 2011, at 9:02 PM, Shannon Spires wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Wow. This little exchange was a mind-blower. My jaw is hanging open. My naive, childish illusions of software competence have been dashed.
If bridges were built with this level of professionalism, people would die and engineers would be jailed.
I've heard that "the difference between a Porsche and a Ferrari is that the Porsche was designed by people who went to college." All this time, I had sort of assumed
Porsche:Ferrari :: Apple:Microsoft.
Guess not.
It's time somebody wrote an operating system with the same degree of engineering rigor that Germans use to design cars. Are we yet tired enough of this kind of crap to do something about it?
[Gary wrote:]
</pre>
<blockquote type="cite">
<pre wrap="">Apple's documentation for mach_thread_self() (see
<a href="http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/man/mach_thread_self.html?txt" class="moz-txt-link-rfc2396E"><http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/man/mach_thread_self.html?txt></a>)
doesn't seem to explicitly state that that function increments the
port's send reference count (though it certainly seems to.) The GNU
Hurd documentation does state this, but warns the user that
mach_thread_self() allows the reference count to silently wrap around
(wrap around 2^32 ? what ?) without error and that the reference count
shouldn't be decremented if this overrun might have happened.
This stuff escaped from a lab somewhere; the fact that it's been
lurching around the countryside frightening villagers as long as it
has is pretty sad.
I don't care what a thread's Mach port's send right's reference count
is. I do care that thread creation doesn't leak kernel resources, and
because if this nonsense it does.
</pre>
</blockquote>
<pre wrap="">[then mikel evins wrote:]
</pre>
<blockquote type="cite">
<pre wrap="">However, during the investigation, we ended up talking over the issues with Avie Tevanian, who was the boss of that stuff at NeXT at that time, and who was before that involved in the design and construction of Mach at CMU. What struck me about the conversations was that Avie said Mach was designed to leak certain resources because allowing them to leak avoided some costly houskeeping, and in "normal use" the leaks would not be a problem. Mach's designers simply assumed that systems would be rebooted often enough to prevent any issues arising.
I remember that he seemed slightly put out that NeXT customers would use system calls in a way that violated that assumption.
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Openmcl-devel mailing list
<a href="mailto:Openmcl-devel@clozure.com" class="moz-txt-link-abbreviated">Openmcl-devel@clozure.com</a>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" class="moz-txt-link-freetext">http://clozure.com/mailman/listinfo/openmcl-devel</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Openmcl-devel mailing list
<a href="mailto:Openmcl-devel@clozure.com" class="moz-txt-link-abbreviated">Openmcl-devel@clozure.com</a>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" class="moz-txt-link-freetext">http://clozure.com/mailman/listinfo/openmcl-devel</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
Openmcl-devel mailing list
<a href="mailto:Openmcl-devel@clozure.com" class="moz-txt-link-abbreviated">Openmcl-devel@clozure.com</a>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" class="moz-txt-link-freetext">http://clozure.com/mailman/listinfo/openmcl-devel</a>
</pre>
</blockquote>
</body>
</html>