Less commas
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
Re: Less commas
On Fri, Dec 31, 2010 at 2: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.
>
>
>
> 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?
Re: Less commas
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
Re: Less commas
On Fri, Dec 31, 2010 at 4:17 AM, bearophile 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.
Re: Less commas
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.
Re: Less commas
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
Re: Less commas
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.
Re: Less commas
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
Re: Less commas
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
Re: Less commas
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
Re: Less commas
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).
Re: Less commas
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?
Re: Less commas
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
Re: Less commas
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? 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
Re: Less commas
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
Re: Less commas
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.
Re: Less commas
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.
Re: Less commas
On Sun, 02 Jan 2011 20:56:48 + Peter Alexander 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? Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Less commas
On Sun, 02 Jan 2011 13:21:33 -0800 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. Thank you for pointing (& re-pointing) at that, Walter. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Less commas
On 1/2/11 4:30 PM, spir wrote: On Sun, 02 Jan 2011 20:56:48 + Peter Alexander 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
Re: Less commas
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
Re: Less commas
2011/1/2 Peter Alexander : > 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.
Re: Less commas
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.
Re: Less commas
On Sun, 02 Jan 2011 21:04:07 +0100, 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).
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)):
...
Re: Less commas
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!
Re: Less commas
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
Re: Less commas
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.
Re: Less commas
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.)
Re: Less commas
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.
Re: Less commas
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
