bearophile wrote:
> But there are many C++ programmers that don't use exceptions, for
> example they are not allowed in Google C++ code: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
>  So surely not 100% of D code will use exceptions. That's why I have
> said that D avoids some of those problems but not all them :-)

I don't know why Google proscribes exceptions, but exceptions still have an uneasy relationship with C++. Older compilers may not support them properly, much C++ code uses them incorrectly and inconsistently, there isn't good support for exception safety or transaction safety, being able to throw value types is a big mistake, etc.

sybrandy wrote:
>>> - Use Before Test: here the bugs are in the code paths of the try-except.
>>
>> Not sure what this means.
> 
> If I remember correctly from when I had an opportunity to look at these types of tools, this is a case where, in C or C++, you have a variable that may be uninitialized or set to NULL, but you don't test for it until you have tried to use it.  I believe the root cause of this bug has nothing to do with the language, but with people going back into code they don't fully understand and trying to either A) use the variable and not know that the check is in there or B) they put the check in to "fix" a bug, but didn't put it in the correct spot.

That makes sense.


> Needless to say, with D setting variables to reasonable defaults, I believe this is mitigated, but not entirely prevented.

You're right.

Walter Bright:
> I don't know why Google proscribes exceptions,

If you look at that link, and you click on the arrow, you will see a nice list of pro-cons :-)

Bye,
bearophile

On 2010-02-09 19:26:05 -0500, bearophile <bearophileHUGS@lycos.com> said:

> Walter Bright:
>> I don't know why Google proscribes exceptions,
> 
> If you look at that link, and you click on the arrow, you will see a nice list of pro-cons :-)

And below the pro-cons it says they avoid exceptions because they have a lot of exception-unsafe code that would break if you were to throw exceptions, suggesting it might be otherwise if it wasn't for that legacy code.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Tue, 9 Feb 2010, Walter Bright wrote:

> @safe guarantees memory safety, so these are non-issues in D.
> 
> Using @safe makes these non-issues.
> 
> As you say, exceptions solve these problems.
> 
> It is a mistake to rely on the GC to free resources other than memory. Properly, either RAII or scope guard statements should be used, as these do not leak.
> 
> No analysis tool can help you if you initialize things to the wrong value. That's very, very different from initializing things to GARBAGE and then using those garbage values.
> 
> We've certainly had long threads about this one. I'll just state that turning on the optimizer will detect many cases of dereferencing null pointers.
> 
> dmd already flags dead code.

Nice black and white world you are acting like you live in there Walter. I know you know better, so why do you pretend otherwise?

You're assuming perfect use of the language and largely simple code. Granted, there's a lot of things that D does better, and the tools in the language make it easier to write better code... but developers are corner cutters at heart.  Additionally, not everything can be done in @safe (or it wouldn't be an optional mode), and not everything can use RAII for resource management.

Coverity, as has been discussed here in the past, is a very powerful tool that solves very real world problems... at an astronomical price.  A sort-of close cousin to Coverity is Fortify.  Fortify has a security slant to it, but is solving essentially the same class of problems.

Compilers do, in concept, a lot of the things that Coverity does, but at a very different scale.  Coverty is aimed at whole application long range effect analysis.  It's got good tools for over-time analysis of builds to help ensure incremental improvements (ie, prevent quality slipping backwards).  All in all, it's well engineered for large systems and large teams.

I wish I had access to it for everthing I develop.  Sadly, the cost is too high.

Later,
Brad

Brad Roberts wrote:
> Nice black and white world you are acting like you live in there Walter.  I know you know better, so why do you pretend otherwise?

First off, yes, if you program in C style, despite using D, your code is vulnerable to many of the problems that Coverity detects.

> You're assuming perfect use of the language and largely simple code.  Granted, there's a lot of things that D does better, and the tools in the language make it easier to write better code... but developers are corner cutters at heart.  Additionally, not everything can be done in @safe (or it wouldn't be an optional mode), and not everything can use RAII for resource management.

Yes, I am relying on convention to a degree for D to be helpful, and I've often enough railed against relying on convention. So why the contradiction?

Let's take the lock()/unlock() pairing problem. In C, you often wind up with a rat's nest of control flow that gets really hard to verify has the unlock() along all paths. Coverity is a win here. In C++, you can wrap the lock()/unlock() in a struct and use RAII, but that's as ugly as sin and many will eschew it, thus Coverity wins again. But in D,

    lock();
    scope(exit) unlock();

and you're done. There's nothing left to analyze. Nothing makes you write D code that way, but I contend that it is easy to write it that way (which addresses the corner cutters), and it is easy for a code review to verify it. No tangle of logic must be traced. So the problem is reduced from a 10 to a 1. It doesn't go away, but the payback of Coverity for these cases is greatly reduced.

(And the cost of Coverity isn't just the purchase price, it has significant administration and false positive costs.)

About @safe: a lot of Coverity is focussed on memory safety, for example it spends a lot of effort analyzing use of C string functions. With @safe, the D compiler guarantees your code is memory safe. No false positives. The idea is to reduce the @system parts of your code to as small a fraction as possible. Then, you aren't running a million lines of code through Coverity to check for memory safety, you're running only a few percent of it, and those few percent will be a lot easier to review.


> Compilers do, in concept, a lot of the things that Coverity does, but at a very different scale.  Coverty is aimed at whole application long range effect analysis.  It's got good tools for over-time analysis of builds to help ensure incremental improvements (ie, prevent quality slipping backwards).  All in all, it's well engineered for large systems and large teams.
> 
> I wish I had access to it for everthing I develop.  Sadly, the cost is too high.

D has moved a lot towards supplying by default a lot of what Coverity claims to do. By making such an expensive tool irrelevant for D, we can make D much more cost effective.

"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:hkt3gq$19pp$1@digitalmars.com...
> On 2010-02-09 19:26:05 -0500, bearophile <bearophileHUGS@lycos.com> said:
>
>> Walter Bright:
>>> I don't know why Google proscribes exceptions,
>>
>> If you look at that link, and you click on the arrow, you will see a nice list of pro-cons :-)
>
> And below the pro-cons it says they avoid exceptions because they have a lot of exception-unsafe code that would break if you were to throw exceptions, suggesting it might be otherwise if it wasn't for that legacy code.
>

It doesn't just suggest it, it flat-out states it:
"Things would probably be different if we had to do it all over again from
scratch."

Walter Bright wrote:
> bearophile wrote:
>> But there are many C++ programmers that don't use exceptions, for
>> example they are not allowed in Google C++ code: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
>>  So surely not 100% of D code will use exceptions. That's why I have
>> said that D avoids some of those problems but not all them :-)
> 
> I don't know why Google proscribes exceptions, but exceptions still have an uneasy relationship with C++. Older compilers may not support them properly, much C++ code uses them incorrectly and inconsistently, there isn't good support for exception safety or transaction safety, being able to throw value types is a big mistake, etc.

If C++ exceptions are thrown and caught within, and are completely self-
-contained within, a (C++) library then nobody should be the wiser.

The only possible issue can be about whether the library should
be allowed to propagate exceptions across the API boundary and
into client code.

The pro and con arguments should take the client code interaction /
API context into consideration.  Otherwise it's just a blatant,
ill-considered consideration (ill-pun considered as well).

Cheers

Justin Johansson

Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:

> D has moved a lot towards supplying by default a lot of what Coverity claims to do. By making such an expensive tool irrelevant for D, we can make D much more cost effective.

D doesn't provide non-nullable types and local refs can still escape the scope easily. There are several kinds of bugs that cause null pointer exceptions / segfaults. Now it took me 2 minutes to come up two examples:

class foo {
  Object a;
  this(Object a) { a = a; }

  void bar() { a.toString(); }

  Object[] baz() {
    scope Object a = new Object;
    return  [ a ];
  }
}

void main() {
  auto a = new Object;
//  auto b = new foo(a);   // segfault
//  b.baz()[0].toString(); // segfault
}

retard wrote:
> Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
> 
>> D has moved a lot towards supplying by default a lot of what Coverity
>> claims to do. By making such an expensive tool irrelevant for D, we can
>> make D much more cost effective.
> 
> D doesn't provide non-nullable types

Yes, there have been a couple long threads about that. Dereferencing a null pointer is a bug, but not a security/safety issue.

> and local refs can still escape the scope easily.

Yes, that is a problem, and we've been trying to fix that.