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