• bearophile <bearophileHUGS lycos.com> Oct 05 2009

bearophile <bearophileHUGS lycos.com> writes:

I am Sorry for my delay for this small answer...

Walter Bright:


5. dead code (code that can never be executed)<


In particular whole unused functions, methods, classes, modules, packages.
Also rather important unused constants, variables.
GCC has a function attribute named "used" that tells the optimizer to keep a
function in the binary even if it appears to be unused (because it may be used
in strange ways from asm, etc).


The =void case is rare enough to be irrelevant.<


In good D code it's very uncommon, but spotting such bugs too is positive.
(And eventually D variables may not be initialyzed anymore?)


6. Arrays are solidly covered by a runtime check. There is code in the
optimizer to detect many cases of overflows at compile time, but the code is
currently disabled because the runtime check covers 100% of the cases.<


Spotting such bugs at compile time, where possible, is 200% better (if such
test is reliable).


8. D2 has acquired some decent checking for this.<


In my opinion it's not enough, some optional runtime tests too are be useful.


More along these lines will be interesting.<


Sure. There's a lot that can be done still.


Other possible bugs:
- optional runtime errors when a pointer goes out of the allocated memory (C#
does something like this).
- safety: people that try to mess with the stack to try to break the safety of
a program. Also stack canaries (now they can be used wuith LLVM).
- errors in indentation, when an if-then-else has an indentation that's the
opposite of the its semantics. New GCC can spot this problem.
- finding where a structure is modified, but such changes will not influence
the program, because the structure is copied by value. This is tricky, but I've
fallen in this trap, for example modifying a struct array, if you don't use
"ref" you will not change the original array. If inside a function that takes a
string in input you change the string length, such string will not be seen
outside the function unless you mark the string as "ref", etc.
- Spotting bugs in "switch", for example where a programmer may have forgotten
a break. I don't know if this can be done, probably not.
- There are many other possibile bugs. I suggest to read online lists of common
bugs in C/C++/Java/C# programs, and to try to give the compiler ways to spot
some of them. Lints like Splint and gimpel are designed for this, see below.
- disallowing implicit signed=>unsigned conversions.


You can also take a look at Splint:
http://www.splint.org/

Splint also shows that adding few annotations in the source code can save from
many bugs. Annotations for example that assert that a pointer is never null,
etc.

And gimpel:
http://www.gimpel.com/
The bug of the month now is interactive, so you can use it to test how good
this software is:
http://www.gimpel-online.com/bugsLinkPage.html
The very large list of possible bugs/problems spotted by gimpel software:
http://gimpel-online.com/MsgRef.html

The Cyclone language is a safe variant of C, it can give some ideas.

C#4 too has surely some safety ideas that D is missing still.
For example warning every time a variable is supposed to be converted
automatically into another type of variable with some information loss (eg.
double => float, etc).

Bye,
bearophile