Thu, 30 Sep 2010 21:12:53 -0400, bearophile wrote:

> Here (pdf alert) I have found a very simple but interesting paper that has confirmed an hypothesis of mine.
> 
> This is a page that contains a pdf that shows a short introduction to the paper: http://www.ganssle.com/tem/tem80.htm
> 
> This is the paper, "Using Redundancies to Find Errors", by Yichen Xie and Dawson Engler, 2002: www.stanford.edu/~engler/p401-xie.pdf
> 
> 
> A trimmed down quote from the tem80 page:
> 
>>Researchers at Stanford have just released a paper detailing their use of automated tools
> to look for redundant code in 1.6 million lines of Linux. "Redundant" is
> defined as: - Idempotent operations (like assigning a variable to
> itself) - Values assigned to variables that are not subsequently used -
> Dead code
> - Redundant conditionals
> 
> They found that redundancies, even when harmless, strongly correlate with bugs. Even when the extra code causes no problems, odds are high that other, real, errors will be found within a few lines of the redundant operations.
> 
> Block-copied code is often suspect, as the developer neglects to change things needed for the code’s new use. Another common problem area:
error
> handlers, which are tough to test, and are, in data I’ve gathered, a huge source of problems in deployed systems. The authors note that their use of lint has long produced warnings about unused variables and return codes, which they've always treated as harmless stylistic issues. Now it's clear that lint is indeed signalling something that may be critically important. The study makes me wonder if compilers that optimize out dead code to reduce memory needs aren't in fact doing us a disservice. Perhaps they should error and exit instead.

If you've ever compiled open source code, you probably have noticed that some developers take software quality seriously. Their programs show no warnings/errors on compile time. That's not very impressive, when the code is below 5000 LOC, but if you apply the same principle when the codebase grows to 500000 LOC, it's a big win.

OTOH, there are lots of projects with lazy bastards developing them. Something ALWAYS breaks. A minor update from gcc ?.?.0 to ?.?.1 seems to be enough to break something. The developers were too lazy to study even the basic functionality of C and seem rather surprised when the compiler prevents data corruption or segfaults or other indeterministic states. I always treat code with lots of these bugs as something completely rotten. In distros like Gentoo these bugs prevent people from actually installing and using the program.

> class Foo {
>     int x, y;
>     this(int x_, int y_) {
>         this.x = x;
>         y = y;
> 
>     }
> }
> void main() {}

Some languages prevent this bug by making the parameters immutable in some sense (at least shallow immutability). It's even possible in Java, and in one place I worked previously "final params by default" was one of the rules in code review and style guides.

On 01/10/2010 02:12, bearophile wrote:
<snip>
>> Researchers at Stanford have just released a paper detailing their use of automated tools
> to look for redundant code in 1.6 million lines of Linux. "Redundant" is defined as:
> - Idempotent operations (like assigning a variable to itself)
<snip>

Idempotent operations are not necessarily redundant.

For example,

    x = y;

is idempotent, but not redundant.  But performing the same idempotent operation multiple times in succession is an example of redundancy.

Really, section 2 of that paper isn't about idempotence at all.

For those who aren't sure what idempotent means, put simply it means that performing the operation multiple times in succession has the same effect as performing it only once.

But assigning a variable to itself is indeed redundant, because it has no effect.

Stewart.

Fri, 01 Oct 2010 12:38:26 +0200, Simen kjaeraas wrote:

> Daniel Gibson <metalcaedes@gmail.com> wrote:
> 
>> this(int this.x, int this.y, int a)
> 
> Me likes.

Looks almost like Scala:

class MyClass(var x: Int, var y: Int, a: Int) {
...
}

retard wrote:
> Some languages prevent this bug by making the parameters immutable in some sense (at least shallow immutability). It's even possible in Java, and in one place I worked previously "final params by default" was one of the rules in code review and style guides.

this(const int x, const int y) { ... }

On 10/2/10, retard <re@tard.com.invalid> wrote:
> Thu, 30 Sep 2010 21:12:53 -0400, bearophile wrote:
>
>> Here (pdf alert) I have found a very simple but interesting paper that has confirmed an hypothesis of mine.
>>
>> This is a page that contains a pdf that shows a short introduction to the paper: http://www.ganssle.com/tem/tem80.htm
>>
>> This is the paper, "Using Redundancies to Find Errors", by Yichen Xie and Dawson Engler, 2002: www.stanford.edu/~engler/p401-xie.pdf
>>
>>
>> A trimmed down quote from the tem80 page:
>>
>>>Researchers at Stanford have just released a paper detailing their use of automated tools
>> to look for redundant code in 1.6 million lines of Linux. "Redundant" is
>> defined as: - Idempotent operations (like assigning a variable to
>> itself) - Values assigned to variables that are not subsequently used -
>> Dead code
>> - Redundant conditionals
>>
>> They found that redundancies, even when harmless, strongly correlate with bugs. Even when the extra code causes no problems, odds are high that other, real, errors will be found within a few lines of the redundant operations.
>>
>> Block-copied code is often suspect, as the developer neglects to change things needed for the code’s new use. Another common problem area:
> error
>> handlers, which are tough to test, and are, in data I’ve gathered, a huge source of problems in deployed systems. The authors note that their use of lint has long produced warnings about unused variables and return codes, which they've always treated as harmless stylistic issues. Now it's clear that lint is indeed signalling something that may be critically important. The study makes me wonder if compilers that optimize out dead code to reduce memory needs aren't in fact doing us a disservice. Perhaps they should error and exit instead.
>
> If you've ever compiled open source code, you probably have noticed that some developers take software quality seriously. Their programs show no warnings/errors on compile time. That's not very impressive, when the code is below 5000 LOC, but if you apply the same principle when the codebase grows to 500000 LOC, it's a big win.
>
> OTOH, there are lots of projects with lazy bastards developing them. Something ALWAYS breaks. A minor update from gcc ?.?.0 to ?.?.1 seems to be enough to break something. The developers were too lazy to study even the basic functionality of C and seem rather surprised when the compiler prevents data corruption or segfaults or other indeterministic states. I always treat code with lots of these bugs as something completely rotten. In distros like Gentoo these bugs prevent people from actually installing and using the program.
>

Don't forget pragma abuse! I don't have the exact source, but I've seen code like this in several medium-big sized projects:

// Shut up stupid compiler warnings
#pragma (DISABLE, 5596)
#pragma (DISABLE, 5597)
#pragma (DISABLE, 5598)

So not only do people neglect warnings, they get annoyed with them but then decide the best solution is to silence the compiler.

OTOH in some cases the warnings are caused by 3rd party libraries and the warnings are re-enabled for user-code again (I've seen this latter case used in Scintilla or Scite).

Thu, 14 Oct 2010 17:21:39 +0200, Andrej Mitrovic wrote:

> Don't forget pragma abuse! I don't have the exact source, but I've seen code like this in several medium-big sized projects:
> 
> // Shut up stupid compiler warnings
> #pragma (DISABLE, 5596)
> #pragma (DISABLE, 5597)
> #pragma (DISABLE, 5598)
> 
> So not only do people neglect warnings, they get annoyed with them but then decide the best solution is to silence the compiler.
> 
> OTOH in some cases the warnings are caused by 3rd party libraries and the warnings are re-enabled for user-code again (I've seen this latter case used in Scintilla or Scite).

Ah, true. Makes one wonder, if C/C++ as systems programming languages are not limiting the programmer unlike impractical high level languages, why do you need to hack the simple warning/error system..