On 7/16/2016 5:32 AM, Andrew Godfrey wrote:
On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote:
But in C++, everything is @system. I'm not sure how people successfully create
enormous programs with it.
I work on Microsoft Word. I'm not sure how much I can share about internal
verification tools, but I can say: We do have SAL annotation:
https://msdn.microsoft.com/en-us/library/ms235402.aspx
Thanks for taking the time to post about your experience with it. Comparing D
with SAL is a worthwhile exercise.
As solutions go, SAL is dissatisfyingly incomplete, and not an easy
mini-language to learn (I still haven't managed it, I look up what I need on the
occasions that I need it). But it does impress at times with what it can catch.
It goes a bit beyond memory safety, too, so I would guess that there are bug
patterns it can catch that D currently won't.
I've seen SAL before, but have not studied it. My impression is it is much more
complex than necessary. For example,
https://msdn.microsoft.com/en-us/library/hh916383.aspx
describes annotations to memcpy(). I believe these are better handled by use of
dynamic arrays and transitive const. But there's no doubt that careful use of
SAL will reduce bugs.
One class of bug I find interesting here is uninitialized variables. I'm not
sure if Visual Studio helps here (we have an internal tool, I know some 3rd
party tools do this too). But it's interesting that these tools can (often, not
always) spot code paths where a variable doesn't get initialized. D's approach
to this helps strongly to avoid using uninitialized memory, but in so doing, it
discards the information these tools are using to spot such bugs. (So, the kind
of bug D lets slip through here would tend to be one where variable foo's value
is foo.init but it should have been initialized to some other value).
Uninitialized variables, along with their cousin adding a field to a struct and
forgetting to initialize it in one of its constructors, have caused me endless
problems and cost me untold hours. It was a major motivator to solve this
problem in D, and I am pleased that my problems with it have been essentially
eliminated.
You write that SAL still leaves undetected cases of uninitialized variables. I
think I'd rather live with the limitation you mentioned in the D way rather than
risk uninitialized variables. Having a predictable wrong value in a variable is
debuggable, having an unpredictable wrong value is often not debuggable, which
is why they consume so much time.
