Article: Finding memory bugs in D code with AddressSanitizer

Walter Bright newshound2 at digitalmars.com
Tue Dec 26 02:34:45 UTC 2017


On 12/25/2017 3:17 PM, Johan Engelen wrote:
> On Monday, 25 December 2017 at 20:31:18 UTC, Walter Bright wrote:
>>
>> Thanks for the great article! Some suggestions:
> 
> Thanks for your comments, I've incorporated them (to my liking).
> 
>> 1. The gray-on-white text is not very legible.
> 
> Looks great here, I like it, sorry. (made it completely black now, can't see the 
> difference here though)

It's still significantly harder to read than text in another font of the same 
size. I have to move close to the screen to read it. Perhaps its the line width 
being too narrow. Perhaps the issue is just with my screen, which has a high 
pixel density. (The boldface text is very readable, for comparison.)



> The article is not meant as a marketing piece (only for ASan), but also 
> shouldn't be  overly critical of D. Hope that the balance is a bit better now 
> with the modifications.

It is better, thank you.

For better or worse, it is always about marketing (or as I prefer it, 
"framing"). We're at a critical time with D, and framing D as being just as bad 
as C++ is going to turn people away.

C++ has many memory safe features, and you can write memory safe code in C++ 
with some discipline. The trouble is, however, that those features are library 
features, and the compiler cannot check them.

This is fundamentally different from D's approach, which is a language approach 
where unsafe operations can be detected at compile time. AS is still useful with 
D, however, because D allows one to escape into unsafe systems programming, and 
in detecting implementation bugs.


More information about the Digitalmars-d-announce mailing list