digitalmars.D - Re: Less commas
- bearophile <bearophileHUGS lycos.com> Jan 02 2011
- Walter Bright <newshound2 digitalmars.com> Jan 02 2011
- Peter Alexander <peter.alexander.au gmail.com> Jan 02 2011
- Walter Bright <newshound2 digitalmars.com> Jan 02 2011
- Walter Bright <newshound2 digitalmars.com> Jan 02 2011
- Eric Poggel <dnewsgroup2 yage3d.net> Jan 03 2011
- Walter Bright <newshound2 digitalmars.com> Jan 03 2011
- Adam D. Ruppe <destructionator gmail.com> Jan 03 2011
- Walter Bright <newshound2 digitalmars.com> Jan 03 2011
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jan 02 2011
- Brad Roberts <braddr puremagic.com> Jan 02 2011
- "Simen kjaeraas" <simen.kjaras gmail.com> Jan 02 2011
- "Manfred_Nowak" <svv1999 hotmail.com> Jan 02 2011
- Daniel Gibson <metalcaedes gmail.com> Jan 03 2011
- "Manfred_Nowak" <svv1999 hotmail.com> Jan 03 2011
- spir <denis.spir gmail.com> Jan 02 2011
- spir <denis.spir gmail.com> Jan 02 2011
- Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> Jan 03 2011
- "Patrick Kreft" <patrick_kreft gmx.net> Jan 03 2011
Walter:If you really want to be productive with this, rather than sitting back and thinking up imaginary problems, do things like peruse the bug database of a large open source project. Look for patterns of problems that might be headed off with language solutions.
A common bug in Linux kernel: if(!state->card-> ac97_status&CENTER_LFE_ON) val&=~DSP_BIND_CENTER_LFE; The fix is to replace (!E & C) with (!(E & C)). Currently D acts like C: void main() { uint x, y; if (!x & y) {} } - 96 instances of this bug in Linux from 2.6.13 (August 2005) to v2.6.28 (December 2008). - 58 instances of this bug in 2.6.20 (February 2007) - 2 in Linux-next (October 10, 2009) They have faced and reduced the number of such bugs using Coccinelle, see pages 8-9 here: http://coccinelle.lip6.fr/papers/fosdem10.pdf See you later, bearophile
Jan 02 2011
bearophile wrote:A common bug in Linux kernel: if(!state->card-> ac97_status&CENTER_LFE_ON) val&=~DSP_BIND_CENTER_LFE; The fix is to replace (!E & C) with (!(E & C)). Currently D acts like C: void main() { uint x, y; if (!x & y) {} } - 96 instances of this bug in Linux from 2.6.13 (August 2005) to v2.6.28 (December 2008). - 58 instances of this bug in 2.6.20 (February 2007) - 2 in Linux-next (October 10, 2009) They have faced and reduced the number of such bugs using Coccinelle, see pages 8-9 here: http://coccinelle.lip6.fr/papers/fosdem10.pdf
This is great stuff, bearophile. Thanks for finding that. Please add this as an enhancement request to bugzilla (disallowing (!x&y) expressions).
Jan 02 2011
On 2/01/11 8:04 PM, Walter Bright wrote:bearophile wrote:A common bug in Linux kernel: if(!state->card-> ac97_status&CENTER_LFE_ON) val&=~DSP_BIND_CENTER_LFE; The fix is to replace (!E & C) with (!(E & C)). Currently D acts like C: void main() { uint x, y; if (!x & y) {} } - 96 instances of this bug in Linux from 2.6.13 (August 2005) to v2.6.28 (December 2008). - 58 instances of this bug in 2.6.20 (February 2007) - 2 in Linux-next (October 10, 2009) They have faced and reduced the number of such bugs using Coccinelle, see pages 8-9 here: http://coccinelle.lip6.fr/papers/fosdem10.pdf
This is great stuff, bearophile. Thanks for finding that. Please add this as an enhancement request to bugzilla (disallowing (!x&y) expressions).
That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than &? Or have I totally misunderstood the cause of the bug?
Jan 02 2011
Peter Alexander wrote:That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than &? Or have I totally misunderstood the cause of the bug?
That's the interesting part, and why I suggested that studying recurring patterns of real life bugs is productive. What we think might be a problem vs what actually is a problem can be very different.
Jan 02 2011
Walter Bright wrote:That's the interesting part, and why I suggested that studying recurring patterns of real life bugs is productive. What we think might be a problem vs what actually is a problem can be very different.
This also reminds me of how the reliability of aircraft engines was improved during WW2. The engines were mounted on a test stand and simply run at full power until they broke. The broken part was analyzed, redesigned, installed, and the engine run again until it broke. Rinse, repeat.
Jan 02 2011
On 1/2/2011 4:30 PM, Walter Bright wrote:Walter Bright wrote:That's the interesting part, and why I suggested that studying recurring patterns of real life bugs is productive. What we think might be a problem vs what actually is a problem can be very different.
This also reminds me of how the reliability of aircraft engines was improved during WW2. The engines were mounted on a test stand and simply run at full power until they broke. The broken part was analyzed, redesigned, installed, and the engine run again until it broke. Rinse, repeat.
I wonder if they ever tried shooting bullets at them until they broke. In WW2 that's an equally real-life scenario!
Jan 03 2011
Eric Poggel wrote:I wonder if they ever tried shooting bullets at them until they broke. In WW2 that's an equally real-life scenario!
They did analyze battle damage with the aim of reducing the vulnerability. I think this was successful, as from what I understand US aircraft were significantly more resistant to damage.
Jan 03 2011
Walter wrote:I think this was successful, as from what I understand US aircraft were significantly more resistant to damage.
I remember reading about something interesting with regard to that (don't remember where though): they looked at planes coming back from combat, and the places *without* bullet holes are the places they worked on - adding armor, etc. Why? The planes that got shot in those areas didn't make it home, so damage there must be more critical than the other hits! (Naturally, this is based on the assumption that the gunfire was generally random and they had a large sample size, but those assumptions worked for WW2 planes.)
Jan 03 2011
Adam D. Ruppe wrote:Walter wrote:I think this was successful, as from what I understand US aircraft were significantly more resistant to damage.
I remember reading about something interesting with regard to that (don't remember where though): they looked at planes coming back from combat, and the places *without* bullet holes are the places they worked on - adding armor, etc. Why? The planes that got shot in those areas didn't make it home, so damage there must be more critical than the other hits! (Naturally, this is based on the assumption that the gunfire was generally random and they had a large sample size, but those assumptions worked for WW2 planes.)
Battle damage on aircraft was not random. Pilots tended to know where the weak spots were, and the most effective angles to attack from. They also knew where their own machines were vulnerable, and would adjust their attacks to minimize risk. For example, the most effective attack on a B-17 was head on, and they'd aim for the pilot (the B-17 later got a chin turret to help with this). It was also the least risky for the Me-109 pilots, as the heavy engine block would protect them while head on, and it was a nearly impossible deflection shot to hit them while they passed. One example of learning from battle damage is they switched bundles of wires from being encased in metal conduit to being just loosely tied together. Hitting the conduit would take out the whole bundle, while if they were just tied together, only the wires directly in the path were cut.
Jan 03 2011
On 1/2/11 4:30 PM, spir wrote:On Sun, 02 Jan 2011 20:56:48 +0000 Peter Alexander<peter.alexander.au gmail.com> wrote:This is great stuff, bearophile. Thanks for finding that. Please add this as an enhancement request to bugzilla (disallowing (!x&y) expressions).
That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than&? Or have I totally misunderstood the cause of the bug?
That's not such surprising: a study on the topic (operator priority) has shown a very high frequency of such errors (in C). The public were all highly educated, tranined, experienced, programmers. On the other hand, the same study showed how ridiculous the proportion of lines of code holding poly-operator expressions is (which comparatively still highers the relative frequency of errors). A logical conclusions is , I guess: is it worth complexifying a language (by a sub-language just for expressions, which is often the bigger and most complicated part of a parser)& causing loads of bugs for a need that arises even 1000th lines of code?
I'd say that a class of bugs that occurs every 1000 lines, is traceable to a unique cause, is mechanically detectable with ease, and is easy to avoid by the programmer, is a MUST to eliminate through language design. Phobos has 90K lines. If I could eliminate 90 bugs in it by a recompile, that would be awesome. By the way - if (a & b == 0) is another one (Don worked on that). Andrei
Jan 02 2011
On 1/2/2011 12:56 PM, Peter Alexander wrote:On 2/01/11 8:04 PM, Walter Bright wrote:bearophile wrote:A common bug in Linux kernel: if(!state->card-> ac97_status&CENTER_LFE_ON) val&=~DSP_BIND_CENTER_LFE; The fix is to replace (!E & C) with (!(E & C)). Currently D acts like C: void main() { uint x, y; if (!x & y) {} } - 96 instances of this bug in Linux from 2.6.13 (August 2005) to v2.6.28 (December 2008). - 58 instances of this bug in 2.6.20 (February 2007) - 2 in Linux-next (October 10, 2009) They have faced and reduced the number of such bugs using Coccinelle, see pages 8-9 here: http://coccinelle.lip6.fr/papers/fosdem10.pdf
This is great stuff, bearophile. Thanks for finding that. Please add this as an enhancement request to bugzilla (disallowing (!x&y) expressions).
That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than &? Or have I totally misunderstood the cause of the bug?
I haven't read the paper, probably should, but is it counting found, fixed, introduced? Each of those are different data points. Also of interest would be any indicator of total bug counts during that same period. We're talking about a LONG period of time here (5-6 years) and a rather large code base that does a lot of low level bit manipulations. Later, Brad
Jan 02 2011
Peter Alexander <peter.alexander.au gmail.com> wrote:That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than &? Or have I totally misunderstood the cause of the bug?
No, you got the cause right. However, how often are you actually interested in doing (!foo)&bar? The language can very well disallow such syntax, because most of the time, it's not what you want it to do. -- Simen
Jan 02 2011
Walter Bright wrote:disallowing (!x&y) expressions
While `!x&y' may be replaced by `y&!x', for `!x&&y' an isomorphic change is not possible. -manfred
Jan 02 2011
Am 02.01.2011 22:21, schrieb Manfred_Nowak:Walter Bright wrote:disallowing (!x&y) expressions
While `!x&y' may be replaced by `y&!x', for `!x&&y' an isomorphic change is not possible. -manfred
(!x) && y may actually be desired, (!x) & y most probably not, so !x&y should be forbidden and !x&&y should not.
Jan 03 2011
Daniel Gibson wrote:so !x&y should be forbidden and !x&&y should not
Some my feel a repel to the language, when the compiler accepted `!x&&y' but then rejects the delete of a `&' to get `!x&y'.(!x) && y
-manfred
Jan 03 2011
On Sun, 02 Jan 2011 20:56:48 +0000 Peter Alexander <peter.alexander.au gmail.com> wrote:This is great stuff, bearophile. Thanks for finding that. Please add this as an enhancement request to bugzilla (disallowing (!x&y) expressions). =20
That really surprises me that it's a common bug. Isn't it obvious that !=
has higher precedence than &? Or have I totally misunderstood the cause=20 of the bug?
That's not such surprising: a study on the topic (operator priority) has sh= own a very high frequency of such errors (in C). The public were all highly= educated, tranined, experienced, programmers.=20 On the other hand, the same study showed how ridiculous the proportion of l= ines of code holding poly-operator expressions is (which comparatively stil= l highers the relative frequency of errors). A logical conclusions is , I guess: is it worth complexifying a language (b= y a sub-language just for expressions, which is often the bigger and most c= omplicated part of a parser) & causing loads of bugs for a need that arises= even 1000th lines of code? Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Jan 02 2011
On Sun, 02 Jan 2011 13:21:33 -0800 Walter Bright <newshound2 digitalmars.com> wrote:That's the interesting part, and why I suggested that studying recurring=
patterns of real life bugs is productive. What we think might be a proble=
what actually is a problem can be very different.
Thank you for pointing (& re-pointing) at that, Walter. Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Jan 02 2011
2011/1/2 Peter Alexander <peter.alexander.au gmail.com>:That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than &? Or have I totally misunderstood the cause of the bug?
The purpose of a higher-level language IMO, is to make it easier for the developer to express his/her intentions, and pitfalls like this should be avoided. IMHO, the most important job of a high-level language is to encourage good programming practices. There's a reason why people aren't seriously using Brainfuck. It's not because it's not turing-complete, it's because it's simply difficult to get right. There's also a reason why "object oriented" languages were invented. It's not because you can't do object-oriented code in C, it's because object orientation in an object-oriented language is easier and more readable. Programming languages is all about encouraging preferred models.
Jan 03 2011
On Sun, 02 Jan 2011 21:04:07 +0100, Walter Bright <newshound2 digitalmars.com> wrote:bearophile wrote:A common bug in Linux kernel: if(!state->card-> ac97_status&CENTER_LFE_ON) val&=~DSP_BIND_CENTER_LFE; The fix is to replace (!E & C) with (!(E & C)). Currently D acts like C: void main() { uint x, y; if (!x & y) {} } - 96 instances of this bug in Linux from 2.6.13 (August 2005) to v2.6.28 (December 2008). - 58 instances of this bug in 2.6.20 (February 2007) - 2 in Linux-next (October 10, 2009) They have faced and reduced the number of such bugs using Coccinelle, see pages 8-9 here: http://coccinelle.lip6.fr/papers/fosdem10.pdf
This is great stuff, bearophile. Thanks for finding that. Please add this as an enhancement request to bugzilla (disallowing (!x&y) expressions).
The false-positive are shown in the presentation ... okey it's was irony, or not? Better is that: let is = func[T](state: ref const T, of: val T -> bool): return !(state & of) if(is(state=obj.flag, of=MAYBE_THIS_STATE)): ...
Jan 03 2011