More evidence that memory safety is the future for programming languages

Johan j at j.nl
Thu Apr 2 17:58:44 UTC 2020


On Thursday, 2 April 2020 at 10:04:24 UTC, Jacob Carlborg wrote:
> On Wednesday, 1 April 2020 at 21:44:27 UTC, Walter Bright wrote:
>
>> gets detected by static analysis. This one does not:
>>
>>     int* bar(int* p) { return p; }
>>
>>     int* foo(int i) { return bar(&i); }
>
> The Clang static analyzer detects this:
>
> $ clang --analyze main.c
> main.c:2:19: warning: Address of stack memory associated with 
> local variable 'i' returned to caller
> int* foo(int i) { return bar(&i); }
>          ~~~~~    ^~~~~~~~~~~~~~
> 1 warning generated.

Come on, of course such a super simple example is detected by 
clang's static analyzer. From my Inkscape days, I remember a case 
where the static analyzer found a bug with 80+ steps across 
multiple cpp files and complex control flow. I imagine Clang's 
analyzer is doing similar proofs that the D compiler is doing. My 
guess is that the problem is similar to the halting problem. And 
memory issues like this are just not provable (I think): 
https://github.com/dlang/dmd/pull/7050

Running the program with a sanitizer (memory, threads, UB, ...) 
appears easier to me in the many cases where this is possible. 
Nice to see you are advocating it Atila! :)

My only point was to question the newness of the news in OP and 
the statement that we need to "get on the bus". C++ has had 
powerful static analysis engines for a long time, and I don't 
think it changed the landscape. C++ has very nice runtime 
sanitizers, but again I don't think it is changing the landscape 
as much as one may have expected.

-Johan



More information about the Digitalmars-d mailing list