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