January 02, 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

January 03, 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?
Assembler is "obvious". People don't always get that right either.

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.
January 03, 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.
January 04, 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)):
    ...
January 04, 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!
January 04, 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
Of course it is an option to allow `!' only after an opening parantheses.

-manfred

January 04, 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.
January 04, 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.)
January 04, 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.
1 2
Next ›   Last »