www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - what are the most common bugs in your D apps?

reply davidl <davidl 126.com> writes:
Actually I'm not sure about what kind of bugs my d apps usually have. But  
I notice that the harmonia project(I now make it uptodate) gets the  
problem of integer overlapping(actually I find it quite hard to detect and  
fix).

What's your opinion and experience?
Apr 05 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Apr 6, 2009 at 12:07 AM, davidl <davidl 126.com> wrote:
 Actually I'm not sure about what kind of bugs my d apps usually have. But I
 notice that the harmonia project(I now make it uptodate) gets the problem of
 integer overlapping(actually I find it quite hard to detect and fix).
What the hell is "integer overlapping"?
Apr 05 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:
 On Mon, Apr 6, 2009 at 12:07 AM, davidl <davidl 126.com> wrote:
 Actually I'm not sure about what kind of bugs my d apps usually have. But I
 notice that the harmonia project(I now make it uptodate) gets the problem of
 integer overlapping(actually I find it quite hard to detect and fix).
What the hell is "integer overlapping"?
I'm assuming overflow
Apr 05 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Robert Fraser Wrote:
 I'm assuming overflow<
Which could be 95% solved by buffer overflow checks :-) My ears are ringing. Bye, bearophile
Apr 05 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Apr 6, 2009 at 2:33 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Robert Fraser Wrote:
 I'm assuming overflow<
Which could be 95% solved by buffer overflow checks :-) My ears are ringing.
For what it's worth, mine aren't. I have never had a bug due to integer overflow. No, I take that back - I have had bugs relating to integer overflow, but they were exclusively limited to things like: for(uint i = len; i >= 0; i--) .... That is, signed/unsigned comparisons. This is the only time I've ever had such problems.
Apr 06 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
davidl Wrote:
 Actually I'm not sure about what kind of bugs my d apps usually have.
I suggest every serious programmer to keep a document that contains all the bugs he/she/shi has fixed in her/his/hir code, plus a note that explains such bug a bit. This is a bug I have put 3 times in my D programs, that shows an-error prone design detail of D arrays: import std.stdio: writefln; void process(int[] arr) { arr.length = arr.length / 2; foreach (i, ref el; arr) el += 2; } void main() { auto a = new int[10]; process(a); writefln(a); } I think D arrays have to be passed by reference by default or they have to be immutable. Such mixed thing just leads to troubles. I have had another class troubles while translating C to do D. Global variables in C are initialized to 0, while in D floating point values (global too) are initialized to nan (or now signaling nan in D2), this leads to different results. There are several other bugs I have had in D. The good thing is that, I am used to use lot of unit testing, so I can catch many of them. Around I see lot of D code with too few unittests (for example most of the code in Phobos has just few unittests. That's bad). Bye, bearophile
Apr 05 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 There are several other bugs I have had in D. The good thing is that,
 I am used to use lot of unit testing, so I can catch many of them.
 Around I see lot of D code with too few unittests (for example most
 of the code in Phobos has just few unittests. That's bad).
Sure, but if you've got more unittests for phobos, email them to me!
Apr 06 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
davidl wrote:
 
 Actually I'm not sure about what kind of bugs my d apps usually have. 
 But I notice that the harmonia project(I now make it uptodate) gets the 
 problem of integer overlapping(actually I find it quite hard to detect 
 and fix).
 
 What's your opinion and experience?
Null references/segfaults. Which could be 90% solved by non-nullable types.
Apr 05 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Apr 6, 2009 at 2:24 AM, Robert Fraser
<fraserofthenight gmail.com> wrote:
 davidl wrote:
 Actually I'm not sure about what kind of bugs my d apps usually have. But
 I notice that the harmonia project(I now make it uptodate) gets the problem
 of integer overlapping(actually I find it quite hard to detect and fix).

 What's your opinion and experience?
Null references/segfaults. Which could be 90% solved by non-nullable types.
Same here.
Apr 06 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Jarrett Billingsley Wrote:

 On Mon, Apr 6, 2009 at 2:24 AM, Robert Fraser
 <fraserofthenight gmail.com> wrote:
 davidl wrote:
 Actually I'm not sure about what kind of bugs my d apps usually have. But
 I notice that the harmonia project(I now make it uptodate) gets the problem
 of integer overlapping(actually I find it quite hard to detect and fix).

 What's your opinion and experience?
Null references/segfaults. Which could be 90% solved by non-nullable types.
Same here.
I've had plenty of those recently. The argument that they're easy to track down is a myth. On linux, the cause the program to core dump and gdb support has been broken all year... It's even more fun when it takes 10 minutes of execution to reproduce it.
Apr 06 2009
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Jason House wrote:
 Jarrett Billingsley Wrote:
 
 On Mon, Apr 6, 2009 at 2:24 AM, Robert Fraser
 <fraserofthenight gmail.com> wrote:
 davidl wrote:
 Actually I'm not sure about what kind of bugs my d apps usually have. But
 I notice that the harmonia project(I now make it uptodate) gets the problem
 of integer overlapping(actually I find it quite hard to detect and fix).

 What's your opinion and experience?
Null references/segfaults. Which could be 90% solved by non-nullable types.
Same here.
I've had plenty of those recently. The argument that they're easy to track down is a myth. On linux, the cause the program to core dump and gdb support has been broken all year... It's even more fun when it takes 10 minutes of execution to reproduce it.
I mainly encounter them when using C bindings. Then I just add a bunch of contracts everywhere I use a pointer retrieved from a C function.
Apr 06 2009
prev sibling parent Don <nospam nospam.com> writes:
Jason House wrote:
 Jarrett Billingsley Wrote:
 
 On Mon, Apr 6, 2009 at 2:24 AM, Robert Fraser
 <fraserofthenight gmail.com> wrote:
 davidl wrote:
 Actually I'm not sure about what kind of bugs my d apps usually have. But
 I notice that the harmonia project(I now make it uptodate) gets the problem
 of integer overlapping(actually I find it quite hard to detect and fix).

 What's your opinion and experience?
Null references/segfaults. Which could be 90% solved by non-nullable types.
Same here.
I've had plenty of those recently. The argument that they're easy to track down is a myth. On linux, the cause the program to core dump and gdb support has been broken all year... It's even more fun when it takes 10 minutes of execution to reproduce it.
Me too. It's also hard to track down when in a Windows DLL. Especially when it's timing-related and only exposed intermittently by hardware. Having just tried some hacking of the DMD source, I can confirm that they're indeed really easy to track down when you're writing a compiler. Unfortunately, not all situations are so easy.
Apr 06 2009
prev sibling next sibling parent downs <default_357-line yahoo.de> writes:
davidl wrote:
 
 Actually I'm not sure about what kind of bugs my d apps usually have.
 But I notice that the harmonia project(I now make it uptodate) gets the
 problem of integer overlapping(actually I find it quite hard to detect
 and fix).
 
 What's your opinion and experience?
I'd say it's forgetting to bind stack variables to a delegate literal, leading to subtle crashes later on. This could be "fixed" by adding a short hash to every stackframe, then comparing that on external variable access (in debug mode). Of course, since 2.0 has effectively obsoleted this problem, there's little point :)
Apr 05 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
davidl wrote:
 
 Actually I'm not sure about what kind of bugs my d apps usually have. 
 But I notice that the harmonia project(I now make it uptodate) gets the 
 problem of integer overlapping(actually I find it quite hard to detect 
 and fix).
 
 What's your opinion and experience?
Logic errors. After that, segfaults, which are especially annoying because I don't get stack traces.
Apr 06 2009
prev sibling next sibling parent reply Weed <resume755 mail.ru> writes:
davidl пишет:
 
 Actually I'm not sure about what kind of bugs my d apps usually have.
 But I notice that the harmonia project(I now make it uptodate) gets the
 problem of integer overlapping(actually I find it quite hard to detect
 and fix).
 
 What's your opinion and experience?
I can not get used that copying of classes through the assign symbol ("=") does not copy them as in C++
Apr 09 2009
parent "Nick Sabalausky" <a a.a> writes:
"Weed" <resume755 mail.ru> wrote in message 
news:grlsqk$245u$1 digitalmars.com...
 davidl пишет:
 Actually I'm not sure about what kind of bugs my d apps usually have.
 But I notice that the harmonia project(I now make it uptodate) gets the
 problem of integer overlapping(actually I find it quite hard to detect
 and fix).

 What's your opinion and experience?
I can not get used that copying of classes through the assign symbol ("=") does not copy them as in C++
I've thought a number of times that it would be nice if Object offered ".dup" (Or at least I don't think it does, does it?). As it is, if we want to copy classes we have to manually create a copy method for each class (although maybe a mixin could do it?).
Apr 10 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from davidl (davidl 126.com)'s article
 Actually I'm not sure about what kind of bugs my d apps usually have. But
 I notice that the harmonia project(I now make it uptodate) gets the
 problem of integer overlapping(actually I find it quite hard to detect and
 fix).
 What's your opinion and experience?
I've been thinking about this, and I've come to realize that subtle high-level logic errors are my most frustrating (if not most common) bugs. In other words, the bugs that really are a pain are more often bugs where I didn't mean what I should have meant at a relatively high (algorithmic) level rather than implementation bugs like integer overflows, null pointers, off by one errors and other such low level bugs, where the problem was more about coding what I meant. More specifically, things like forgetting to deal with special cases and boundary conditions bite me very frequently and are much more annoying and difficult to deal with than any low-level bug. For example, just about every time I've gotten a null pointer error, it was due to some special case that I had overlooked. Until people invent a way to read the programmer's mind, I don't think the language can really help much here.
Apr 10 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
The following one isn't a problem of D, it's a small bug I've created while
translating C code to D.
Here I have reduced the code to a very small proggy, so you probably need only
a moment to spot the problem.
This program takes a string that contains more than one natural numbers, and
returns their sum.
Example:
200+350 => 550

The original C code:

#include <stdio.h>

int main() {
    char* numbers = "200 350";

    int total = 0;
    char* p = &numbers[0];
    int cur = 0;

    while (*p != 0) {
        char c = (*p) - 48;
        if (c >= 0) {
            cur = (cur * 10) + c;
        } else {
            total += cur;
            cur = 0;
        }
        p++;
    }
    total += cur;

    printf("total: %d\n", total);
    return 0;
}


The D code is exactly the same, but it contains a bug:

import std.stdio: printf;

int main() {
    char* numbers = "200 350";

    int total = 0;
    char* p = &numbers[0];
    int cur = 0;

    while (*p != 0) {
        char c = (*p) - 48;
        if (c >= 0) {
            cur = (cur * 10) + c;
        } else {
            total += cur;
            cur = 0;
        }
        p++;
    }
    total += cur;

    printf("total: %d\n", total);
    return 0;
}

A C programmer probably needs 5 seconds to spot the bug.
There is a standard way for a compiler to avoid such bugs.
Later I may paste here another bug created from porting C code to D.
I think a FAQ can be created to list such most common troubles.

Bye,
bearophile
Apr 12 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Apr 12, 2009 at 9:28 AM, bearophile <bearophileHUGS lycos.com> wrot=
e:
 The following one isn't a problem of D, it's a small bug I've created whi=
le translating C code to D.
 Here I have reduced the code to a very small proggy, so you probably need=
only a moment to spot the problem.
 This program takes a string that contains more than one natural numbers, =
and returns their sum.
 Example:
 200+350 =3D> 550

 The original C code:

 #include <stdio.h>

 int main() {
 =A0 =A0char* numbers =3D "200 350";

 =A0 =A0int total =3D 0;
 =A0 =A0char* p =3D &numbers[0];
 =A0 =A0int cur =3D 0;

 =A0 =A0while (*p !=3D 0) {
 =A0 =A0 =A0 =A0char c =3D (*p) - 48;
 =A0 =A0 =A0 =A0if (c >=3D 0) {
 =A0 =A0 =A0 =A0 =A0 =A0cur =3D (cur * 10) + c;
 =A0 =A0 =A0 =A0} else {
 =A0 =A0 =A0 =A0 =A0 =A0total +=3D cur;
 =A0 =A0 =A0 =A0 =A0 =A0cur =3D 0;
 =A0 =A0 =A0 =A0}
 =A0 =A0 =A0 =A0p++;
 =A0 =A0}
 =A0 =A0total +=3D cur;

 =A0 =A0printf("total: %d\n", total);
 =A0 =A0return 0;
 }
Your C code also contains a bug, if chars are unsigned. I will agree, however, that the D compiler (*all* compilers for all languages, really!) should detect and complain about "nontrivial trivial" comparisons - comparisons that *look* nontrivial (like "c >=3D 0"), but which always evaluate to true or always to false.
Apr 12 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Jarrett Billingsley" <jarrett.billingsley gmail.com> wrote in message 
news:mailman.1145.1239546503.22690.digitalmars-d puremagic.com...
On Sun, Apr 12, 2009 at 9:28 AM, bearophile <bearophileHUGS lycos.com> 
wrote:
 Your C code also contains a bug, if chars are unsigned.

 I will agree, however, that the D compiler (*all* compilers for all
 languages, really!) should detect and complain about "nontrivial
 trivial" comparisons - comparisons that *look* nontrivial (like "c >=
 0"), but which always evaluate to true or always to false.
I agree with what you're saying about "nontrivial trivial comparisons", but I'm inclined to also suggest that arithmetic operations be disallowed for char types. It doesn't make any more semantic sence than trying to add a string with an int. Plus, the concept of signed/unsigned for a "character" is rather nonsensical as well. If you want to manipulate chars like that, you're not really looking to manipulate the characters themselves, you're looking to manipulate the underlying numerical codes. So a cast to a numeric type should be required.
Apr 12 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 12 Apr 2009 20:46:37 +0400, Nick Sabalausky <a a.a> wrote:

 "Jarrett Billingsley" <jarrett.billingsley gmail.com> wrote in message
 news:mailman.1145.1239546503.22690.digitalmars-d puremagic.com...
 On Sun, Apr 12, 2009 at 9:28 AM, bearophile <bearophileHUGS lycos.com>
 wrote:
 Your C code also contains a bug, if chars are unsigned.

 I will agree, however, that the D compiler (*all* compilers for all
 languages, really!) should detect and complain about "nontrivial
 trivial" comparisons - comparisons that *look* nontrivial (like "c >=
 0"), but which always evaluate to true or always to false.
I agree with what you're saying about "nontrivial trivial comparisons", but I'm inclined to also suggest that arithmetic operations be disallowed for char types. It doesn't make any more semantic sence than trying to add a string with an int. Plus, the concept of signed/unsigned for a "character" is rather nonsensical as well. If you want to manipulate chars like that, you're not really looking to manipulate the characters themselves, you're looking to manipulate the underlying numerical codes. So a cast to a numeric type should be required.
I second that.
Apr 12 2009