Lints, Condate and bugs

bearophile bearophileHUGS at lycos.com
Wed Oct 27 18:03:08 PDT 2010


Walter:

> When you find yourself adding semantic annotations to the C code, or providing
> extra semantic rules to the static analyzer, what that really is saying is that
> the abstract type abilities of the language being analyzed are deficient.

Right. Some of my recent suggestions like the @outer or the @optional_tag() ( http://d.puremagic.com/issues/show_bug.cgi?id=5125 ) attributes are ways to give more semantics to the D compiler.

On the other hand Cyclone (and heavily annotated C code for Splint) shows that too many annotations make code writing an unpleasant experience (or even a pain. Writing D2 code is a bit more painful just because of const correctness), so you must keep a balance. That idea about islands in that dynamic dependent types paper is a possible way to solve this problem with annotations.


> I found lint useful for maybe a year or so, and then it just stopped finding any
> problems in my code.

I am using C for quite more than a year, yet I find useful a good lint. You are surely much better than me in C.


> Microsoft's Managed C++ does exactly this. While a technical success, it is a
> complete failure in regards to pleasing programmers.

I see.


> I'm also very familiar with using multiple pointer types, which are a necessity
> for DOS programming. I'm sick of it. It sucks. I don't want to go back to it,
> and I don't know anyone who does.

I see. I will need to program more in Ada to see if you are right regarding the why Ada uses pointers.


> I know about data flow analysis, and I was able to implement such checking for
> array bounds. But it is of only limited effectiveness.

This is interesting. You have done lot of things.
(Time ago I have used the Java SciMark 2.0 benchmark before and after the introduction of that static analyis and I have seen the difference.)


> as I haven't seen any focus on them in static analysis tools.

Most lints don't focus on them because they are hard to spot statically, especially if you use C language. To avoid overflow bugs with a static analysis you need big guns, as done by SPARK on a subset of Ada, but it's a language for special purposes.


> [integer overflows]
> 50% slower than C++ means that people will not switch from C++ to D. I think a
> total 5% slowdown relative to C++ is about the max acceptable.
> ...
> In particular, I do not view integer overflows as remotely big enough of a
> problem to justify such massive slowdowns.

(There I was talking about integer overflows.) I answer with one of your answers:

> That's why it's selectable with a switch.

(But for integral overflows in D I suggest two switches, one for unsigned and one for both signed and unsigned values).


> Yes, I've had an overflow bug here
> and there over the years, but nothing remotely as debilitating as uninitialized
> data bugs or pointer bugs.

D allows you to remove a large percentage of the memory-related bugs, so now the percentage of integer-related bugs (over the new total of bugs) becomes higher :-)

Thank you for your many answers.

Bye,
bearophile


More information about the Digitalmars-d mailing list