digitalmars.D - what are the most common bugs in your D apps?
- davidl (5/5) Apr 05 2009 Actually I'm not sure about what kind of bugs my d apps usually have. Bu...
- Jarrett Billingsley (2/5) Apr 05 2009 What the hell is "integer overlapping"?
- Robert Fraser (2/8) Apr 05 2009 I'm assuming overflow
- bearophile (5/6) Apr 05 2009 Which could be 95% solved by buffer overflow checks :-)
- Jarrett Billingsley (8/12) Apr 06 2009 For what it's worth, mine aren't. I have never had a bug due to
- bearophile (19/20) Apr 05 2009 I suggest every serious programmer to keep a document that contains all ...
- Walter Bright (2/6) Apr 06 2009 Sure, but if you've got more unittests for phobos, email them to me!
- Robert Fraser (2/9) Apr 05 2009 Null references/segfaults. Which could be 90% solved by non-nullable typ...
- Jarrett Billingsley (3/11) Apr 06 2009 Same here.
- Jason House (2/15) Apr 06 2009 I've had plenty of those recently. The argument that they're easy to tra...
- Christopher Wright (3/17) Apr 06 2009 I mainly encounter them when using C bindings. Then I just add a bunch
- Don (7/21) Apr 06 2009 Me too. It's also hard to track down when in a Windows DLL.
- downs (3/10) Apr 05 2009 I'd say it's forgetting to bind stack variables to a delegate literal, l...
- Christopher Wright (3/10) Apr 06 2009 Logic errors. After that, segfaults, which are especially annoying
- Weed (4/11) Apr 09 2009
- Nick Sabalausky (6/16) Apr 10 2009 I've thought a number of times that it would be nice if Object offered
- dsimcha (13/18) Apr 10 2009 I've been thinking about this, and I've come to realize that subtle high...
- bearophile (53/53) Apr 12 2009 The following one isn't a problem of D, it's a small bug I've created wh...
- Jarrett Billingsley (10/36) Apr 12 2009 le translating C code to D.
-
Nick Sabalausky
(12/17)
Apr 12 2009
"Jarrett Billingsley"
wrote in message - Denis Koroskin (2/24) Apr 12 2009 I second that.
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
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
Jarrett Billingsley wrote:On Mon, Apr 6, 2009 at 12:07 AM, davidl <davidl 126.com> wrote:I'm assuming overflowActually 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
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
On Mon, Apr 6, 2009 at 2:33 AM, bearophile <bearophileHUGS lycos.com> wrote:Robert Fraser Wrote: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.I'm assuming overflow<Which could be 95% solved by buffer overflow checks :-) My ears are ringing.
Apr 06 2009
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
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
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
On Mon, Apr 6, 2009 at 2:24 AM, Robert Fraser <fraserofthenight gmail.com> wrote:davidl wrote:Same here.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 06 2009
Jarrett Billingsley Wrote:On Mon, Apr 6, 2009 at 2:24 AM, Robert Fraser <fraserofthenight gmail.com> wrote: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.davidl wrote:Same here.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 06 2009
Jason House wrote:Jarrett Billingsley Wrote: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.On Mon, Apr 6, 2009 at 2:24 AM, Robert Fraser <fraserofthenight gmail.com> wrote: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.davidl wrote:Same here.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 06 2009
Jason House wrote:Jarrett Billingsley Wrote: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.On Mon, Apr 6, 2009 at 2:24 AM, Robert Fraser <fraserofthenight gmail.com> wrote: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.davidl wrote:Same here.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 06 2009
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
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
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
"Weed" <resume755 mail.ru> wrote in message news:grlsqk$245u$1 digitalmars.com...davidl пишет: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?).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 10 2009
== Quote from davidl (davidl 126.com)'s articleActually 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
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
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
"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
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:I second that.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