www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Less commas

reply bearophile <bearophileHUGS lycos.com> writes:
I'd like to restrict a bit the usage of the comma operator in D2, disallowing
at compile-time some currently usages that some C style guides already suggest
to avoid.

If I see production code like the two examples below in production code, I
change the code, and remove the commas. I think they are confusing, and may
hide bugs. Do you know other situations where you like to disallow the comma
operator in D2? Later I will probably write an enhancement request on this.

----------------

Is x the result of foo() or bar()?

int foo() { return 10; }
int bar() { return 20; }
void main() {
    int x;
    x = foo(), bar();
}

----------------

The comma could be mistaken for a semicolon:

void main() {
    int x;
    if (x > 0) x = 0,
               x = 1;
}

Bye,
bearophile
Dec 31 2010
next sibling parent reply Caligo <iteronvexor gmail.com> writes:
On Fri, Dec 31, 2010 at 2:09 AM, bearophile <bearophileHUGS lycos.com>wrote:


 I'd like to restrict a bit the usage of the comma operator in D2,
 disallowing at compile-time some currently usages that some C style guides
 already suggest to avoid.

 If I see production code like the two examples below in production code, I
 change the code, and remove the commas. I think they are confusing, and may
 hide bugs. Do you know other situations where you like to disallow the comma
 operator in D2? Later I will probably write an enhancement request on this.

 ----------------

 Is x the result of foo() or bar()?

 int foo() { return 10; }
 int bar() { return 20; }
 void main() {
    int x;
    x = foo(), bar();
 }

 ----------------

 The comma could be mistaken for a semicolon:

 void main() {
    int x;
    if (x > 0) x = 0,
               x = 1;
 }

 Bye,
 bearophile


What font are you using?
Dec 31 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Caligo:


 What font are you using?




Inconsolata-g, a very good non-proportional font designed to be used with
anti-aliasing. Its main fault is that it doesn't have bold yet.

One of its features is to tell apart commas and semicolons better, by the way.
In it the lower-case L and the 1 glyphs are easy to tell apart. Yet, the D
choice to deprecate number literals like 1l was the right one.

Bye,
bearophile
Dec 31 2010
parent Caligo <iteronvexor gmail.com> writes:
On Fri, Dec 31, 2010 at 4:17 AM, bearophile <bearophileHUGS lycos.com>wrote:


 Caligo:


 What font are you using?




 Inconsolata-g, a very good non-proportional font designed to be used with
 anti-aliasing. Its main fault is that it doesn't have bold yet.

 One of its features is to tell apart commas and semicolons better, by the
 way. In it the lower-case L and the 1 glyphs are easy to tell apart. Yet,
 the D choice to deprecate number literals like 1l was the right one.

 Bye,
 bearophile


I use Anonymous Pro and I think it does a better job in case of commas and
semicolons.
Dec 31 2010
prev sibling next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 31/12/10 8:09 AM, bearophile wrote:

 I'd like to restrict a bit the usage of the comma operator in D2, disallowing
at compile-time some currently usages that some C style guides already suggest
to avoid.

 If I see production code like the two examples below in production code, I
change the code, and remove the commas. I think they are confusing, and may
hide bugs. Do you know other situations where you like to disallow the comma
operator in D2? Later I will probably write an enhancement request on this.


I don't believe it is the job of the compiler to enforce personal style 
preferences.

If people /really/ want to write obfuscated code then that's up to them 
-- you can't stop them. If organisations want to enforce style guides 
then that's up to them to manually enforce the style or produce tools to 
do it automatically.

Whatever criteria you select for distinguishing acceptable comma use 
from unacceptable comma use will be subjective, and inevitably some 
people will be angered by the decision.

I think that this should be *at most* an optional warning, but even then 
I think it would be a massive waste of programmer time to add this feature.
Dec 31 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Peter Alexander:


 I don't believe it is the job of the compiler to enforce personal style 
 preferences.


D2 compiler enforces several good style preferences. Those two style
preferences are not just mine, they are enforced by a known C lint tool too. So
are the two things I've shown bad/important enough to justify avoiding them?



 If people /really/ want to write obfuscated code then that's up to them 
 -- you can't stop them.


This is a very wrong idea. It's the job of the language designers to avoid some
syntax traps. So the designers need to find a good middle point between chaos
and rigidity.



 If organisations want to enforce style guides 
 then that's up to them to manually enforce the style or produce tools to 
 do it automatically.


Most programmers don't use those tools or style guides, so those tools don't
avoid you to find bad code in the modules you find in some public online
repository. Style guides are not enough to avoid many troubles.



 Whatever criteria you select for distinguishing acceptable comma use 
 from unacceptable comma use will be subjective,


Is this true in the two cases I've shown?

This is a little C program that compiles with no errors and not even warnings
(with -Wall) with GCC 4.5.1:

int main() {
    int x;
    x = 10, 20;
    return 0;
}

The same program compiled with DMD 2.051 produces this error:
test.d(3): Error: long has no effect in expression (20)



 and inevitably some people will be angered by the decision.


That's what discussions and votes are for :-) (Despite some votes have more
weight).

Thank you for your comments,
bye,
bearophile
Dec 31 2010
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
bearophile wrote:


 This is a little C program that compiles with no errors and not even 


warnings (with -Wall) with GCC 4.5.1:

 int main() {
     int x;
     x = 10, 20;
     return 0;
 }


This is totally off topic but gcc's -Wall does not mean "all warning 
options":

   http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

I can't test it now, but -Wunused-value seems to be the option for the 
case above.

Ali
Jan 01 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 I think they are confusing, and may hide bugs.


This is, again, an example of what I was talking about earlier. I've never,
ever 
seen this as an issue in 30 years of programming. There are plenty of problems 
that actually adversely affect programs one can work on. We don't need to spend 
time crafting solutions to problems that affect nobody.

It's like building a set for a movie. The set is meant to be seen only from the 
angle the camera is set up at. Any other angle and the set looks completely 
fake, and it being a facade is obvious. The reason is simple - there's no
reason 
to waste time and money making it look real from any angle other than that of 
the camera.



 The same program compiled with DMD 2.051 produces this error:
 test.d(3): Error: long has no effect in expression (20)


The reason dmd checks for that (and not the former) is that such are actual 
problems that often appear in real code and bedevil programmers.

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.
Dec 31 2010
parent 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.


OK, I will try. Thank you for your answer.

Bye,
bearophile
Jan 01 2011
prev sibling next sibling parent 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 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 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
next sibling 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 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=


=20

 patterns of real life bugs is productive. What we think might be a proble=


m vs=20

 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 reply 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


=20
 That really surprises me that it's a common bug. Isn't it obvious that !=


=20

 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
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 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?


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.
Jan 03 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


Of course it is an option to allow `!' only after an opening parantheses.

-manfred
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
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Brad Roberts:


 I haven't read the paper, probably should,


There are papers about Coccinelle, but the PDF I have linked is just a pack of
few slides :-)



 but is it counting found, fixed, introduced? Each of those are different data
points.


The section in the slides says "Finding and fixing !x&y bugs using Coccinelle",
and at the end it says "Over 450 patches created using Coccinelle accepted into
Linux", so I think it's talking about bugs fixed.



 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.


Surely the total count of Linux bugs in those years is very high, so the
percentage of !x&y bugs is very low. On the other hand to catch higher level
bugs you need a very refined type system, that doesn't seem to go well with the
current D Zen.

I don't have such numbers, but I think it's not too much hard to find how many
bugs have being fixed in that time in Linux. The bug trackers are online.

Bye,
bearophile
Jan 03 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:


 This is great stuff, bearophile. Thanks for finding that. Please add this as
an 
 enhancement request to bugzilla (disallowing (!x&y) expressions).


http://d.puremagic.com/issues/show_bug.cgi?id=5409

Bye,
bearophile
Jan 04 2011