www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Less commas

reply bearophile <bearophileHUGS lycos.com> writes:
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
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent reply Eric Poggel <dnewsgroup2 yage3d.net> writes:
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
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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
parent Walter Bright <newshound2 digitalmars.com> writes:
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
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
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
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
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
prev sibling next sibling parent reply "Manfred_Nowak" <svv1999 hotmail.com> writes:
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
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
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
parent "Manfred_Nowak" <svv1999 hotmail.com> writes:
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
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
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
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
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
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
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
prev sibling parent "Patrick Kreft" <patrick_kreft gmx.net> writes:
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