More evidence that memory safety is the future for programming languages
Timon Gehr
timon.gehr at gmx.ch
Sun Mar 29 02:28:01 UTC 2020
On 29.03.20 03:08, Arine wrote:
> On Saturday, 28 March 2020 at 23:14:05 UTC, rikki cattermole wrote:
>> On 29/03/2020 9:24 AM, Walter Bright wrote:
>>> https://news.ycombinator.com/item?id=22711391
>>>
>>> Fitting in with the push for @safe as the default, and the @live
>>> Ownership/Borrowing system for D.
>>>
>>> We can either get on the bus or get run over by the bus.
>>
>> "This is why D requires and @live attribute be added to functions to
>> enable the checking for just those functions, so it doesn't break
>> every program out there."
>>
>> Interesting quote there.
>
>
> Indeed it is interesting, on one hand, you have @safe being made the
> default, breaking all code in existence. And then you have @live being
> introduced so it doesn't break all code in existence. It seems @live is
> making the same mistake as @safe. How long until @live becomes the default?
> ...
@live will never be the default in any version of D that I am willing to
use. I really don't understand why people are inclined to think it is on
the same level as @safe. It just is not.
>
> I also find this claim to be quite bold:
>
>> This is why D uses DFA to catch 100% of the positives with 0% negatives.
>
> When in the review thread previously the sentiment was along the lines
> of, "patch the holes as they appear". So how do you go from patching
> holes as they appear, to 100% guaranteeing it catches everything
> correctly, without thorough testing. Or is that just empty marketing
> promises?
>
It's not a statement that has a standard meaning. What positives and
what negatives? Refer to the following table:
| problem exists | problem does not exist
----------------------------------------------------------------
flagged by linter | true positive | false positive
----------------------------------------------------------------
not flagged by linter | false negative | true negative
----------------------------------------------------------------
@live leads to any of the four kinds of outcomes:
void foo(int *p)@live{
free(p);
free(p); // true positive
}
void bar(int *p)@live{
auto q=p;
*p=3; // false positive
}
void baz()@live{
auto p=new int;
free(p); // false negative
}
void qux()@life{
auto p=cast(int*)malloc(int.sizeof);
free(p); // true negative
}
An amusing way to interpret 100% positives and 0% negatives would be to
say the linter flags all positives (either true or false) and no
negatives (neither true nor false). That basically means the linter
flags every code as being problematic, which would make it completely
useless.
In the thread on hackernews, there were a few people who interpreted the
statement as saying that the linter has neither false positives nor
false negatives, which is provably impossible. You can get rid of one of
them at a time, but not both. @safe is an example of a feature that does
not have false negatives (unless the implementation is buggy), but of
course it has loads of false positives, for example you cannot manage
memory manually in @safe code without @trusted escapes, even if you do
it correctly.
More information about the Digitalmars-d
mailing list