Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!newsfeed.kamp.net!newsfeed0.kamp.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!newsp.newsguy.com!news2 From: Michael Wojcik Newsgroups: comp.lang.java.programmer Subject: Re: =?UTF-8?B?QW5kcm9pZOKAlFdoeSBEYWx2aWs/?= Date: Wed, 08 Jun 2011 10:10:11 -0400 Organization: Micro Focus Lines: 74 Message-ID: References: NNTP-Posting-Host: p4e30beac8d38a18aebf452b8276cf47d0e69b7d24bf8562e.newsdawg.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5094 Lawrence D'Oliveiro wrote: > In message , Joshua Cranmer wrote: >> I'm sure that outside of GNU or FSF-blessed programs, there are a lot of >> C/C++ programs that wouldn't compile on Unix-ish-but-not-Linux >> platforms, like OpenBSD or Solaris. > > How about this one , with a million lines of C > code, last I counted. Or this one . Or this one > . Or this one . So your claim is that the total number of C and C++ programs, minus four, is less than "a lot"? Though to be honest, I don't really see what the point is. I think Joshua is overestimating the number of C and C++ programs that are specific to Linux and won't build on OpenBSD or Solaris. There are definitely some, but IME they're usually the ones that deliberately use features peculiar to Linux, for whatever reason. (A better argument might have been the number of C and C++ programs that run on x86 Linux but either don't build or fail on one of the pickier UNIXes, such as HP-UX for Itanium. But even then it's a quibble.) What's more important is the generally poor quality of C code. (I think much C++ is also poorly written, but arguing that is more complicated, because it's a far larger language with more latitude for programmer choice.) So let's look at your examples. Blender: Has about 260 open bugs, including memory allocation issues and assertion failures. Much of the source is C++, which I'm not going to look at now; but the C source is problematic. For example, there are a few uses of strncpy. strncpy has broken semantics; it is never the right choice. Blender also includes its own implementation of strncpy (BLI_strncpy), for no readily apparent reason, and most of the code uses that; but it's sub-optimal. It also uses strcpy extensively, and I'm not convinced all of those are safe, for example in the makesrna implementation. That's just from a minute of glancing at the source. MySQL: 145 bugs filed in the past 30 days, some of which are clearly coding errors (eg #61303, #61208). I don't want to take the time right now to prowl through the sources, but the project does not have a great track record; see CVE-2009-2446, CVE-2006-1516 through CVE-2006-1518, CVE-2010-3676 through CVE-2010-3683, and so on. LibreOffice: A fork of the OOo code, which does not have a great track record. Consider CVE-2010-3450 through -3454, etc. And while those CVEs don't list LibreOffice among vulnerable products, the SuSE LibreOffice update claims it's vulnerable (see [1]). I suspect the relative lack of official vulnerability reports for LibreOffice is because they're generally reported against OOo instead. And since LO has significant additional features on top of the OOo base, it has a lot more room for additional mistakes. Apache: An outlier project, with excellent funding and a great many eyes on the code. That hasn't kept it free of errors. Take a look at the brand-new CVE-2011-1921, for example. Or CVE-2011-1928, a classic error in C code, caused by a fix to the earlier CVE-2011-0419. '0419 and '1928 are only DoS vulnerabilities; but that's bad enough. And these are extremely popular projects, so they get a lot of attention. Less-used and less-examined code tends to be much worse. [1] http://secunia.com/advisories/43837/ -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University