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

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.

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

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

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

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.