www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A list of common bugs

reply bearophile <bearophileHUGS lycos.com> writes:
This is from a site of people that sell a static analyser for C/C++ code. Their
periodic articles are usually interesting, this shows some common bugs:

http://www.viva64.com/en/a/0070/

From articles like that I conclude that I'd like compilers/languages to take
more attention to redundancies (like boolean expressions that can be seen at
compile-time to be always false, etc). There is also a good paper about this
topic, "Using Redundancies to Find Errors", by Yichen Xie and Dawson Engler,
2002:
www.stanford.edu/~engler/p401-xie.pdf
I'd like Walter to give DMD more weight/attention to such redundancies, because
they very often hide bugs.

Bye,
bearophile
Mar 17 2011
parent reply Trass3r <un known.com> writes:
bearophile Wrote:
 This is from a site of people that sell a static analyser for C/C++ code.
Their periodic articles are usually interesting, this shows some common bugs:
 
 http://www.viva64.com/en/a/0070/

I guess pushing dmd's source code through that analyzer couldn't hurt as well.
Mar 17 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Trass3r:

 I guess pushing dmd's source code through that analyzer couldn't hurt as well.

Recently I have understood a simple thing, that is why the creators of the SPARK (an Ada subset) compiler have written it using itself, also writing down proof of the whole compiler: you can't create a language that allows to write very bug-free code if its compiler has many bugs, because even if the user programs are bug-free, the bugs in the compiler will produce buggy programs anyway. This means that if D wants to become a quite safe (= low bug count) language, it will need to kill most of the bugs in its compiler(s) too. Bye, bearophile
Mar 17 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
spir:

 First, "eat your own food".

Right, but in the case of the SPARK compiler the main purpose of writing it in SPARK + full proofs is probably to not introduce bugs in user code caused by compiler bugs. Bye, bearophile
Mar 17 2011
prev sibling parent Kagamin <spam here.lot> writes:
spir Wrote:

 First, "eat your own food".
 
 There is another reason for a (low-level static compiled) language to be 
 written in itself: it's a measure of its efficiency. Nicklaus Wirth said the 
 (only) measure of a compiler's efficiency is the speed of compiling itself. If 
 you think very hard ;-), you're probably it is a very very clever assertion. 
 (As a side-effect, this also measures the language core's efficiency.)

Speed is determined by the algorithm complexity, not optimization.
Mar 17 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/17/2011 02:08 PM, bearophile wrote:
 Trass3r:

 I guess pushing dmd's source code through that analyzer couldn't hurt as well.

Recently I have understood a simple thing, that is why the creators of the SPARK (an Ada subset) compiler have written it using itself, also writing down proof of the whole compiler: you can't create a language that allows to write very bug-free code if its compiler has many bugs, because even if the user programs are bug-free, the bugs in the compiler will produce buggy programs anyway. This means that if D wants to become a quite safe (= low bug count) language, it will need to kill most of the bugs in its compiler(s) too.

First, "eat your own food". There is another reason for a (low-level static compiled) language to be written in itself: it's a measure of its efficiency. Nicklaus Wirth said the (only) measure of a compiler's efficiency is the speed of compiling itself. If you think very hard ;-), you're probably it is a very very clever assertion. (As a side-effect, this also measures the language core's efficiency.) Denis -- _________________ vita es estrany spir.wikidot.com
Mar 17 2011