www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.development - Safer D first draft

reply Walter Bright <newshound2 digitalmars.com> writes:
https://github.com/WalterBright/documents/blob/38f0a846726b571f8108f6e63e5e217b91421c86/safer.md
Sep 23
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
Thanks for the reminder, ``a.ptr`` is a perfectly safe operation, it 
exists solely because we do not have type state analysis to prevent 
dereferencing null. It can be a valid argument to non-D code both as 
null and non-null. That check should be removed.

I see there is one other example given, for escape analysis. This is 
where I actually see the value in such a proposal and have thought about 
as part of my own proposals.

Specifically for type state analysis, it is never correct to dereference 
null, therefore it should never be allowed in `` system` code.
Sep 23
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
I should mention, I did not consider the escape analysis in the form 
proposed as being turned on. Depending on how the analysis works, this 
could throw up a lot of false positives, where you want it to be highly 
liberal in what is allowed.

Each error will need confirmation that it is liberal in what it allows, 
and is highly cherry picked on what it disallows. But we can do this on 
a case by case basis, not here.
Sep 23
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
`a.ptr` is an array overflow issue, not a pointer validation issue, as one can 
have an array of 0 length.
Sep 23
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 24/09/2024 1:13 AM, Walter Bright wrote:

 `a.ptr` is an array overflow issue, not a pointer validation issue, as 
 one can have an array of 0 length.


That is a good point, the pointer can be non-null, but length is zero.

At which point yes, can overflow.

Ok, do a length check first and the safety check can be disabled. I'm ok 
with that!
Sep 23
prev sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 23 September 2024 at 13:13:24 UTC, Walter Bright wrote:

 `a.ptr` is an array overflow issue, not a pointer validation 
 issue, as one can have an array of 0 length.


Maybe `Expression.ptr` can be ` safe` if the compiler can 
statically prove that `Expression` has non-zero length or is a 
string literal (which is always zero-terminated).
Sep 24
next sibling parent Nick Treleaven <nick geany.org> writes:
On Tuesday, 24 September 2024 at 19:23:57 UTC, Quirin Schroll 
wrote:

 Maybe `Expression.ptr` can be ` safe` if the compiler can 
 statically prove that `Expression` has non-zero length or is a 
 string literal (which is always zero-terminated).


I implemented that but we need a good rationale to allow that.
https://github.com/dlang/dmd/pull/15581#issuecomment-1709928886
Sep 24
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2024 12:23 PM, Quirin Schroll wrote:

 Maybe `Expression.ptr` can be ` safe` if the compiler can statically prove
that 
 `Expression` has non-zero length or is a string literal (which is always 
 zero-terminated).


Unfortunately, the cases where it can statically prove this are rare. But it 
does what it can:
```
int foo(int i)
{
     int[3] a;
     return a[3];
}
```
```
test.d(5): Error: array index 3 is out of bounds `a[0 .. 3]`
```
Sep 25
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 24 September 2024 at 19:23:57 UTC, Quirin Schroll 
wrote:

 Maybe `Expression.ptr` can be ` safe` if the compiler can 
 statically prove that `Expression` has non-zero length or is a 
 string literal (which is always zero-terminated).


I don't think that's a good idea.

First off, it makes it implementation-defined if a particular 
piece of code complies. When you have `someString.ptr`, It might 
be that compiler A figures out `someString` is never `""`, but 
compiler B doesn't. Therefore, A will accept it in a ` safe` 
function, B won't. Worse, if the function has attribute 
auto-inference, A and B will infer different attributes for the 
function, leading to confusing breakage when switching compilers.

Second, you can work around this by writing `&Expression[0]`. If 
the compiler could figure out that `Expression.ptr` would be 
safe, it can just as well figure out that bounds checks for 
`&Expression[0]` aren't needed.
Oct 04
parent Dukc <ajieskola gmail.com> writes:
On Friday, 4 October 2024 at 09:44:33 UTC, Dukc wrote:

 It might be that compiler A figures out `someString` is never 
 `""`


Actually `""` would be safe if string literals are 
zero-terminated as in DMD. Should probably have written `new 
string(0)` or something.
Oct 04
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 23 September 2024 at 09:02:28 UTC, Walter Bright wrote:

 https://github.com/WalterBright/documents/blob/38f0a846726b571f8108f6e63e5e217b91421c86/safer.md


The DIP says


 Most code is likely written as the default, and the idea is to 
 move such code to  safe.


Does that mean this is intended to be a transitional feature to 
help users migrate their code to a future  safe-by-default 
edition of D? Or are we giving up on  safe-by-default, and 
replacing it with this proposal?
Sep 23
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2024 5:24 AM, Paul Backus wrote:

 Does that mean this is intended to be a transitional feature to help users 
 migrate their code to a future  safe-by-default edition of D? Or are we giving 
 up on  safe-by-default, and replacing it with this proposal?


It means our current method of all-or-nothing with  safe is a bridge too far
for 
a lot of code.

Whether it is transitional or not, the more errors detected at compile time,
the 
better.
Sep 23
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 23 September 2024 at 12:43:03 UTC, Walter Bright wrote:

 On 9/23/2024 5:24 AM, Paul Backus wrote:

 Does that mean this is intended to be a transitional feature 
 to help users migrate their code to a future  safe-by-default 
 edition of D? Or are we giving up on  safe-by-default, and 
 replacing it with this proposal?


 It means our current method of all-or-nothing with  safe is a 
 bridge too far for a lot of code.

 Whether it is transitional or not, the more errors detected at 
 compile time, the better.


In that case, I'm strongly opposed to this.

Fundamentally, this proposal does nothing to make writing  safe 
code easier; it just makes writing non- safe code more annoying. 
It's the bad part of  safe-by-default without the good part.

If you're looking for a less all-or-nothing approach to 
increasing the adoption of  safe, allow me to once again 
recommend universal attribute inference:

https://forum.dlang.org/thread/pfawiqhppkearetcrkno forum.dlang.org
Sep 23
next sibling parent reply Lance Bachmeier <no spam.net> writes:
On Monday, 23 September 2024 at 13:17:23 UTC, Paul Backus wrote:


 In that case, I'm strongly opposed to this.

 Fundamentally, this proposal does nothing to make writing  safe 
 code easier; it just makes writing non- safe code more 
 annoying. It's the bad part of  safe-by-default without the 
 good part.


I agree. I'd actually go a bit further and say that if it's 
turned on by default, if anything, the effect would be to give 
users a false sense of security - they'd be confused why checks 
here and there are missing (I certainly wouldn't understand the 
reasoning). As a permanent compiler switch, the opt-in nature 
would prevent confusion, but that wouldn't require a DIP.
Sep 23
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2024 6:50 AM, Lance Bachmeier wrote:

 I agree. I'd actually go a bit further and say that if it's turned on by 
 default, if anything, the effect would be to give users a false sense of 
 security - they'd be confused why checks here and there are missing (I
certainly 
 wouldn't understand the reasoning).



Consider:
```
int* foo(int i)
{
     return &i;
}
```
which gives an error today by default. I don't think this is confusing.
Sep 23
parent reply Lance Bachmeier <no spam.net> writes:
On Monday, 23 September 2024 at 15:49:28 UTC, Walter Bright wrote:

 On 9/23/2024 6:50 AM, Lance Bachmeier wrote:

 I agree. I'd actually go a bit further and say that if it's 
 turned on by default, if anything, the effect would be to give 
 users a false sense of security - they'd be confused why 
 checks here and there are missing (I certainly wouldn't 
 understand the reasoning).



 Consider:
 ```
 int* foo(int i)
 {
     return &i;
 }
 ```
 which gives an error today by default. I don't think this is 
 confusing.


It's not that the individual checks are confusing. It's the 
opposite. The confusing part would be the cases that aren't being 
checked. There would be no reason for someone new to the language 
to know that they're getting a set of "almost safe" checks on 
their program. I can't imagine implementing something like this 
without making it opt-in.
Sep 23
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2024 11:34 AM, Lance Bachmeier wrote:

 There would be no 
 reason for someone new to the language to know that they're getting a set of 
 "almost safe" checks on their program.


They get that now. There are plenty of checks already.
Sep 23
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2024 6:17 AM, Paul Backus wrote:

 If you're looking for a less all-or-nothing approach to increasing the
adoption 
 of  safe, allow me to once again recommend universal attribute inference:


I'm well aware of universal attribute inference. There are also a number of 
technical problems with it. Meanwhile, we have a lot of legitimate and easy 
checks that are already implemented, we just have to enable them.
Sep 23
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 23 September 2024 at 09:02:28 UTC, Walter Bright wrote:


Unironically why not just grab diffs from opend?



 Sep 24



prev sibling  parent  Dukc <ajieskola gmail.com>  writes:


On Monday, 23 September 2024 at 09:02:28 UTC, Walter Bright wrote:

 https://github.com/WalterBright/documents/blob/38f0a846726b571f8108f6e63e5e217b91421c86/safer.md


The idea that ` trusted` functions will get the same checks as 
default functions is not a good idea. Take a member function of a 
custom array, for instance:

```D
// Currently:
 trusted pure nothrow  nogc opIndex(size_t index)
{   if(index >= length) assert(0);
     return ptr[index];
}

// With this DIP, it has to be:
 trusted pure nothrow  nogc opIndex(size_t index)
{   if(index >= length) assert(0);
     return (()  system => ptr[index])();
}
```

It's going to be a LOT of work to convert all ` trusted` 
functions to be like this.

You could argue it helps the reviewer, as the system code is 
highlighted by these ` system` lambdas. Alas, this would be of 
minimal use. Spotting language-defined unsafe operations, like 
pointer arithmetic and casts of unsafe values, is relatively 
easy. What is harder is spotting calls to ` system` functions, 
since those are different for each codebase and can't be memoized 
unlike language rules.

The proposed rule would help with the easy part but not the hard 
one. So please, leave rules for ` trusted` functions as they are 
now.

In the "Prior work", mention OpenD. It already has a kind of 
"safer by default" which is actually (not far off from what this 
DIP 
suggests)[https://dpldocs.info/this-week-in-arsd/Blog.Posted_2024_03_25.html].

Overall... well I'm not sure. Sure, this DIP would improve safety 
over the present status quo, assuming ` trusted` rules aren't 
changed. But since we have editions, can't we just do a real 
` safe` by default? We could make ` safe` external C functions 
forbidden - they would have to be ` system` or ` trusted`. That 
would avoid the question whether external C functions should be 
exempt from the change.



 Oct 04