www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.ideas - Transition to safe by default

reply Walter Bright <newshound2 digitalmars.com> writes:
As discussed in this thread:

https://www.digitalmars.com/d/archives/digitalmars/D/D_not_considered_memory_safe_374866.html

There are significant problems with making D default to being  safe, with 
respect to transitioning existing code to it. The problems are large enough
that 
I fear it will deter people from putting in the work to make the transition.

The problems are:

1. Programs with cycles in the flow graph. The cycles mean any function in that 
cycle cannot be made  safe until all the functions in the cycle are  safe. My 
experience with transitioning large programs is that transitioning must be done 
incrementally, function by function, testing for no breakage after each change. 
Trying to do it all at once does not work, and never will work.

2. The difficulties in making functions  safe are:

  a. C strings

  b. unions that lay pointers over other values

  c. calling other functions that are not  safe/ trusted

  d. few functions are marked  safe/ trusted/ system

  e. safety inference is not done for most functions for various reasons

  f. safety inference can be problematic for cycles in the function flow graph

3. I proposed marking the unmarked functions  trusted, which will enable  safe 
to be done on a function-by-function basis. Timon objects on the basis of this 
will be lying about the functions having a safe interface, and the programmer
is 
unlikely to complete fixing all of those functions.

I don't have an easy solution for 2.a and 2.b. But the rest boil down to a safe 
function not being able to call a system function. How can we ameliorate this 
problem?

The following is based on an idea that was proposed in that thread.

Function safety is actually in 4 states:

1. unattributed
2.  safe
3.  trusted
4.  system

So I propose "safe by default" to mean, for unattributed functions:

1. do all safety checks *except* checking for calling unattributed functions.

2. calling  system functions in unattributed functions will be flagged

3. calling unattributed functions will not affect attribute inference

----
This will not make the code safe by default. But it will make code a lot safer 
by default, and will provide a transition path. Code passing this will be a lot 
easier to transition to full safety.
Jul 29
next sibling parent Dukc <ajieskola gmail.com> writes:
Walter Bright kirjoitti 29.7.2024 klo 19.40:

 So I propose "safe by default" to mean, for unattributed functions:
 
 1. do all safety checks *except* checking for calling unattributed 
 functions.
 
 2. calling  system functions in unattributed functions will be flagged
 
 3. calling unattributed functions will not affect attribute inference
 
 ----
 This will not make the code safe by default. But it will make code a lot 
 safer by default, and will provide a transition path. Code passing this 
 will be a lot easier to transition to full safety.


This will mean there will be two levels of safety: unattributed and 
` safe`. The only way they differ from each other is that you can't call 
unattributed functions from ` safe`.

Is the idea that unattributed would mean "probably safe but needs deeper 
scrutiny", like how you're using ` trusted` in DMD? Like, occasional 
safewashing would be okay for unattributed functions, or leaving unsafe 
C functions unmarked, but not so much for ` safe` or ` trusted`?

That's an interesting idea actually. Maybe it's the way to go!

I'm slightly worried it might lock us to almost-but-not-quite safe 
future, when people don't finish their job and mark external functions 
as ` system` when needed. But not as worried as I'm about the 
possibility D will stay mostly ` system` if we don't do this.
Jul 29
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
To clarify, this will not change attribute inference.
Jul 29
parent reply Dukc <ajieskola gmail.com> writes:
Walter Bright kirjoitti 29.7.2024 klo 20.23:

 To clarify, this will not change attribute inference.


You mean that if auto-inference is on, it'll work as before, instead of 
complaining you're calling ` system` code, right? Makes sense.

However, from your first post:

 3. calling unattributed functions will not affect attribute inference 


Do you mean an auto-inferred function is still going to be inferred as 
` safe`, not unattributed, if it calls unattributed functions but not 
` system` functions? I suspect this would be met with opposition that 
I'd symphatise with, because of this:

```D
// unattributed
extern(c) void free(void*);

// inferred as  safe!
auto foo() => free(new int);
```
Jul 30
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
What it means is functions that do  system things will have to be marked as 
 system or  trusted.

It kinda turns the attribute inference inside out :-/
Aug 05
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2024 9:24 AM, Dukc wrote:

 ```D
 // unattributed
 extern(c) void free(void*);
 
 // inferred as  safe!
 auto foo() => free(new int);
 ```


That's correct.

What we could do is require functions with no bodies to have an attribute.
Aug 05
prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 30/07/2024 4:40 AM, Walter Bright wrote:

 So I propose "safe by default" to mean, for unattributed functions:
 
  1.
     do all safety checks /except/ checking for calling unattributed
     functions.
  2.
     calling  system functions in unattributed functions will be flagged
  3.
     calling unattributed functions will not affect attribute inference


After changing unattributed with `` unkownsafety`` attribute, this reads 
like it is acting as `` safe`` with no extra steps.

BUT I think I know why!

It is the same diagnostic level!

In ``ErrorSink``:

```d
void memorySafety(Module m, TRUST safetyLevel, const ref Loc loc, 
const(char)* format, ...);
```

It needs to be configurable.

``-msoff dmd.*``
``-mswarn dmd.*``
``-msinfo dmd.*``

By default it could be set to info or off.


Basically, if a function is marked as `` system`` or `` trusted`` you 
don't do the `` safe`` analysis. Otherwise for messages you call this 
function and determines what level to print it as.
Jul 29
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
https://gist.github.com/rikkimax/37cc5db5f381a9adc1dde6a9bbcad46d



| Field           | Value 
            |
|-----------------|-----------------------------------------------------------------|
| DIP:            | (number/id -- assigned by DIP Manager) 
            |
| Author:         | Richard (Rikki) Andrew Cattermole 
<firstname lastname.co.nz>                        |
| Implementation: | (links to implementation PR if any) 
            |
| Status:         | Draft 
            |



This proposal makes D more easily `` safe`` by changing the default 
safety level and introducing new diagnostic logging level.


* [Rationale](#rationale)
* [Prior Work](#prior-work)
* [Description](#description)
* [Breaking Changes and Deprecations](#breaking-changes-and-deprecations)
* [Reference](#reference)
* [Copyright & License](#copyright--license)
* [Reviews](#reviews)



Memory safety is increasing becoming more important to the programming 
field. With a signicant adoption rate of the Rust language, and with it 
governmental organizations becoming less tolerant of failure for compile 
time verifiable things. Furthermore this provides a transition path 
towards safety without preventing those who do not wish to not.



This has many a NewsGroup post about it. Along with a DIP to change the 
default.

TODO: link something



To increase the memory safety of D, `` safe`` must be the default for 
all new code.



This is a two pronged approach, the first is to introduce a new safety 
level, this has until now been the default.

```diff
AtAttribute:
+	  unknownsafety
```

The attribute `` unknownsafety`` may not be marked on a function with a 
body. But may be put on a function pointer.

If a function or a function pointer has not been marked with a safety 
attribute, it is inferred to be `` unknownsafety``.

An `` unknownsafety`` function:
- Must not call an `` system`` function.
- Can call other `` unknownsafety`` functions.
- Will be checked against the `` safe`` checks.

If a `` unknownsafety`` function passes all `` safe`` checks, then it 
will be upgraded to `` safe``.



In the compiler, the second approach takes place.
A new command line switch is added, ``-ms``.
This memory safety switch, will allow setting the diagnostic log level 
and for which module(s) to apply it to for all memory safety check messages.

Example:
- ``-msoff dmd.*``
- ``-mswarn std.*``
- ``-msinfo *``

The default level is info.

All memory safety errors that currently work by `` safe`` would be 
converted to this diagnostic level.



In current D2 edition, the default level will need to be off to prevent 
code breakage.
Otherwise for newer editions it will be info.


Optional links to reference material such as existing discussions, 
research papers
or any other supplementary materials.


Copyright (c) 2024 by the D Language Foundation

Licensed under [Creative Commons Zero 
1.0](https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt)
Jul 29
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
I've changed my mind on disallowing `` unknownsafety`` on functions.

If we allow it, extend this DIP over to `` nogc`` and ``pure`` we could 
get a limited form of contract invalidation for ``opApply``.

``nothrow`` of course is covered by needing to introduce the throws set 
for value type exceptions.

So I'm liking this direction.
Jul 29
parent reply IchorDev <zxinsworld gmail.com> writes:
P.S. ` unknownsafety` is SO long. Maybe it should be something 
like ` inferred`?
Jul 29
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 30 July 2024 at 05:16:40 UTC, IchorDev wrote:

 P.S. ` unknownsafety` is SO long. Maybe it should be something 
 like ` inferred`?


More bikeshedding:  safeDefault?  safeAssume?  safeDirect?
Jul 30
parent bachmeier <no spam.net> writes:
On Tuesday, 30 July 2024 at 13:44:18 UTC, jmh530 wrote:

 On Tuesday, 30 July 2024 at 05:16:40 UTC, IchorDev wrote:

 P.S. ` unknownsafety` is SO long. Maybe it should be something 
 like ` inferred`?


 More bikeshedding:  safeDefault?  safeAssume?  safeDirect?


I prefer  unverified because it's ultimately a question of 
whether it's been verified that it's safe.
Jul 30
prev sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 30/07/2024 5:16 PM, IchorDev wrote:

 P.S. ` unknownsafety` is SO long. Maybe it should be something like 
 ` inferred`?


It would be the default, so length doesn't matter.

Although on that note I am thinking `` infer(safe)`` would be better, 
since that essentially what it is doing.
Jul 30
prev sibling next sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Monday, 29 July 2024 at 18:23:37 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 https://gist.github.com/rikkimax/37cc5db5f381a9adc1dde6a9bbcad46d


I’m really liking this idea, I think this is very close to 
something I’d be fine with. I do have one reservation though:

Even people who want all of their code to be ` safe` (which 
includes myself) often need to use C libraries. Even if you check 
whole libraries to mark functions as ` trusted`, there are 
libraries like OpenGL which require using `__gshared` function 
pointers.
Riki’s DIP appears to address this by (correct me if I’m wrong) 
making it so that these external C functions, when unmarked, can 
be called by unmarked D code. The issue is, unmarked code can be 
upgraded to ` safe`. I think this upgrade process should not 
happen if a function calls an unmarked function with no body. In 
fact, I suggest we make body-less functions ` system` by default.
Jul 29
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 30/07/2024 5:11 PM, IchorDev wrote:

 On Monday, 29 July 2024 at 18:23:37 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 https://gist.github.com/rikkimax/37cc5db5f381a9adc1dde6a9bbcad46d


 
 I’m really liking this idea, I think this is very close to something I’d 
 be fine with. I do have one reservation though:
 
 Even people who want all of their code to be ` safe` (which includes 
 myself) often need to use C libraries. Even if you check whole libraries 
 to mark functions as ` trusted`, there are libraries like OpenGL which 
 require using `__gshared` function pointers.
 Riki’s DIP appears to address this by (correct me if I’m wrong) making 
 it so that these external C functions, when unmarked, can be called by 
 unmarked D code. The issue is, unmarked code can be upgraded to ` safe`. 
 I think this upgrade process should not happen if a function calls an 
 unmarked function with no body. In fact, I suggest we make body-less 
 functions ` system` by default.


Yes, I didn't state this but this is how I've always thought as it is 
based upon what the compiler can prove.
Jul 30
parent reply Brad Roberts <braddr puremagic.com> writes:
On 7/30/2024 12:19 PM, Richard (Rikki) Andrew Cattermole via dip.ideas 
wrote:

(this isn't directed at anyone in particular, and definitely not 
Richard, just happens to be who wrote the below quote this time)


 Yes, I didn't state this but this is how I've always thought as it is 
 based upon what the compiler can prove.


It hasn't come up in a long time, so this is a reasonable time to remind 
everyone that the compiler doesn't prove  safe-ty.  It checks for 
not- safe-ty.  The logic is backwards from what it 'should' be, imho. 
Instead of only allowing known to be safe code, it blocks known to be 
problematic code.  Meaning that omissions in the logic default to open 
rather than closed.

Assuming perfect no-bugs code, the distinction doesn't matter.  But no 
complex system is perfect.  Fixing that part of the implementation might 
make for a great summer of code project for some eager student.

Later,
Brad
Jul 30
parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 30 July 2024 at 20:17:52 UTC, Brad Roberts wrote:

 On 7/30/2024 12:19 PM, Richard (Rikki) Andrew Cattermole via 
 dip.ideas wrote:

 (this isn't directed at anyone in particular, and definitely 
 not Richard, just happens to be who wrote the below quote this 
 time)


 Yes, I didn't state this but this is how I've always thought 
 as it is based upon what the compiler can prove.


 It hasn't come up in a long time, so this is a reasonable time 
 to remind everyone that the compiler doesn't prove ` safe`-ty.  
 It checks for not-` safe`-ty.  The logic is backwards from what 
 it 'should' be, imho. Instead of only allowing known to be safe 
 code, it blocks known to be problematic code.  Meaning that 
 omissions in the logic default to open rather than closed.


There sure is a difference, but it’s a didactic one, not a formal 
one. There is only a finite number of core-language operations. 
And I’m not talking about a formally finite, but humongous 
number, it’s really not that many. Formally, it makes no 
difference listing the allowed ones or the forbidden ones.
Jul 31
prev sibling parent bachmeier <no spam.net> writes:
It would help to expand on the details of -msoff and -msinfo.
Jul 30
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Monday, 29 July 2024 at 16:40:52 UTC, Walter Bright wrote:


 This will not make the code safe by default. But it will make 
 code a lot safer by default, and will provide a transition 
 path. Code passing this will be a lot easier to transition to 
 full safety.


I don't know what problem this would solve. My understanding of 
those wanting safe by default is that it would not move the 
needle at all relative to what's already in the language.

Is there something wrong with

1. Adding a symbol to denote that you want your code to compile 
even though you haven't verified that it's safe. You can use that 
during the transition.
2. Adding a `-safe` switch that won't compile if anything in your 
program is marked with (1). Then people that want safe actually 
get safe.
Jul 29
prev sibling next sibling parent Nick Treleaven <nick geany.org> writes:
On Monday, 29 July 2024 at 16:40:52 UTC, Walter Bright wrote:

 Function safety is actually in 4 states:

 1. unattributed
 2.  safe
 3.  trusted
 4.  system

 So I propose "safe by default" to mean, for unattributed 
 functions:

 1. do all safety checks *except* checking for calling 
 unattributed functions.


And error if an unattributed function does a non-call unsafe 
operation?


 2. calling  system functions in unattributed functions will be 
 flagged


As an error?

Then calling any unattributed function from an unattributed 
function must also be memory-safe, right? So how would 
unattributed be any more permissive than  safe?
Jul 30
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/29/24 18:40, Walter Bright wrote:

 
 So I propose "safe by default" to mean, for unattributed functions:
 ...


Thanks for looking into this kind of thing!


 1. do all safety checks *except* checking for calling unattributed 
 functions.
 
 2. calling  system functions in unattributed functions will be flagged
 
 3. calling unattributed functions will not affect attribute inference
 
 ----
 This will not make the code safe by default. But it will make code a lot 
 safer by default,


What is a characterization of those unattributed functions that are the 
root cause for any lack of memory safety in unattributed functions? Is 
it just `extern(C)` function prototypes? If so, that seems a bit weird.


 and will provide a transition path. Code passing this 
 will be a lot easier to transition to full safety.


I think this is getting somewhere, but probably needs something more to 
become really practical. Some issues I see:

- calling a single ` system` function in an unattributed one would 
disable other safety checks in that unattributed function as it would 
then infer ` system`. It seems this would likely also lead to cases 
where safety checks are enabled in one part of a inferreed-` system` 
function, but not another part.

- there is still no way to enable safety checks in ` trusted` functions.
Jul 30
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2024 1:09 PM, Timon Gehr wrote:

 What is a characterization of those unattributed functions that are the root 
 cause for any lack of memory safety in unattributed functions? Is it just 
 `extern(C)` function prototypes? If so, that seems a bit weird.


Function prototypes can only be taken at face value. If they are unattributed, 
they would be accepted as callable from  safe code. Or we could simply say that 
prototypes would have to be explicitly attributed in order to be callable from 
 safe code.



 - calling a single ` system` function in an unattributed one would disable
other 
 safety checks in that unattributed function as it would then infer ` system`.


Not necessarily. But it would still require the caller to mark the function 
 trusted or  system.



 - there is still no way to enable safety checks in ` trusted` functions.


One can always switch it temporarily to  safe, fix any errors, then put it back.

But in general, trusted code should be a very small part of a program.
Aug 05
next sibling parent reply Mike Shah <mshah.475 gmail.com> writes:
On Tuesday, 6 August 2024 at 00:54:32 UTC, Walter Bright wrote:

 On 7/30/2024 1:09 PM, Timon Gehr wrote:

 What is a characterization of those unattributed functions 
 that are the root cause for any lack of memory safety in 
 unattributed functions? Is it just `extern(C)` function 
 prototypes? If so, that seems a bit weird.


 Function prototypes can only be taken at face value. If they 
 are unattributed, they would be accepted as callable from  safe 
 code. Or we could simply say that prototypes would have to be 
 explicitly attributed in order to be callable from  safe code.



 - calling a single ` system` function in an unattributed one 
 would disable other safety checks in that unattributed 
 function as it would then infer ` system`.


 Not necessarily. But it would still require the caller to mark 
 the function  trusted or  system.



 - there is still no way to enable safety checks in ` trusted` 
 functions.


 One can always switch it temporarily to  safe, fix any errors, 
 then put it back.

 But in general, trusted code should be a very small part of a 
 program.


One thought I had that might be an incremental improvement on 
using  trusted during refactoring is the ability to add a 
'reason' to the attribute (C++ does this for the function that 
are attributed nodiscard --[[nodiscard("some reason here")]].

e.g.

void foo()  trusted("Have not made this function safe yet, still 
refactoring")
{
     // Something not yet refactored to be safe

}

void bar()  trusted("Manually verified by code review to be safe 
on Aug. 12, 2024")
{
     Third_Party_Library_Function_With_Interface_We_Trust_or_Own();
}

 safe SafeFunction(){
   // Calling into 2 'trusted' functions
   foo();
   bar();
}

Some other notes:

- There would be no reason to add a 'reason' for  safe or  system 
code ( safe is verified by the compiler already,  system is known 
to be an 'unsafe' block of code).
- Compiler or tooling could dump out  trusted functions with an 
annotated reason (similar to 'deprecated' messages) to programmer.
Aug 12
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 12 August 2024 at 18:47:02 UTC, Mike Shah wrote:

 On Tuesday, 6 August 2024 at 00:54:32 UTC, Walter Bright wrote:

 On 7/30/2024 1:09 PM, Timon Gehr wrote:

 What is a characterization of those unattributed functions 
 that are the root cause for any lack of memory safety in 
 unattributed functions? Is it just `extern(C)` function 
 prototypes? If so, that seems a bit weird.


 Function prototypes can only be taken at face value. If they 
 are unattributed, they would be accepted as callable from 
  safe code. Or we could simply say that prototypes would have 
 to be explicitly attributed in order to be callable from  safe 
 code.



 - calling a single ` system` function in an unattributed one 
 would disable other safety checks in that unattributed 
 function as it would then infer ` system`.


 Not necessarily. But it would still require the caller to mark 
 the function  trusted or  system.



 - there is still no way to enable safety checks in ` trusted` 
 functions.


 One can always switch it temporarily to  safe, fix any errors, 
 then put it back.

 But in general, trusted code should be a very small part of a 
 program.


 One thought I had that might be an incremental improvement on 
 using  trusted during refactoring is the ability to add a 
 'reason' to the attribute (C++ does this for the function that 
 are attributed nodiscard --[[nodiscard("some reason here")]].

 e.g.

 void foo()  trusted("Have not made this function safe yet, 
 still refactoring")
 {
     // Something not yet refactored to be safe

 }

 void bar()  trusted("Manually verified by code review to be 
 safe on Aug. 12, 2024")
 {
     
 Third_Party_Library_Function_With_Interface_We_Trust_or_Own();
 }

  safe SafeFunction(){
   // Calling into 2 'trusted' functions
   foo();
   bar();
 }

 Some other notes:

 - There would be no reason to add a 'reason' for  safe or 
  system code ( safe is verified by the compiler already, 
  system is known to be an 'unsafe' block of code).
 - Compiler or tooling could dump out  trusted functions with an 
 annotated reason (similar to 'deprecated' messages) to 
 programmer.


Best one yet:

extern(C) int f()  trusted("Implementation is marked  safe");
Aug 13
parent reply Mike Shah <mshah.475 gmail.com> writes:
On Tuesday, 13 August 2024 at 15:44:45 UTC, Quirin Schroll wrote:

 Best one yet:

 extern(C) int f()  trusted("Implementation is marked  safe");


If I own the implementation, is this possible?  Call to f() would 
be ambiguous (See below example).

I think I get your sentiment though :) The 'reason' provided 
could be totally bogus -- BUT it will at least stand out for 
folks aiming for 100%  safe code.

Providing some mechanism to users to indicate if  trusted is 
being used as a bridge between  safe and  system code (intended 
use), or if  trusted is merely being used a temporary fix until 
you refactor cycles later could be useful.

I suppose you could also add your own User Defined Attribute 
(UDA) to indicate the state of the functions "safeness" as well 
though (e.g.  trusted int f()  ("safe_eventually");) -- but that 
doesn't seem very robust.


---------------------------------------
   1 import std.stdio;
   2
   3 extern(C) int f()  trusted;
   4
   5  safe int f(){
   6     return 42;
   7 }
   8
   9 void main(){
  10     f();
  11 }

safe.d(10): Error: `safe.f` called with argument types `()` 
matches both:
safe.d(3):     `safe.f()`
and:
safe.d(5):     `safe.f()`
Failed: ["/usr/bin/dmd", "-v", "-o-", "safe.d", "-I."]
---------------------------------------
Aug 13
parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 13 August 2024 at 20:24:17 UTC, Mike Shah wrote:

 On Tuesday, 13 August 2024 at 15:44:45 UTC, Quirin Schroll 
 wrote:

 Best one yet:

 extern(C) int f()  trusted("Implementation is marked  safe");


 If I own the implementation, is this possible?  Call to f() 
 would be ambiguous (See below example).

 I think I get your sentiment though :) The 'reason' provided 
 could be totally bogus -- BUT it will at least stand out for 
 folks aiming for 100%  safe code.

 Providing some mechanism to users to indicate if  trusted is 
 being used as a bridge between  safe and  system code (intended 
 use), or if  trusted is merely being used a temporary fix until 
 you refactor cycles later could be useful.

 I suppose you could also add your own User Defined Attribute 
 (UDA) to indicate the state of the functions "safeness" as well 
 though (e.g.  trusted int f()  ("safe_eventually");) -- but 
 that doesn't seem very robust.

 ```
   1 import std.stdio;
   2
   3 extern(C) int f()  trusted;
   4
   5  safe int f(){
   6     return 42;
   7 }
   8
   9 void main(){
  10     f();
  11 }

 safe.d(10): Error: `safe.f` called with argument types `()` 
 matches both:
 safe.d(3):     `safe.f()`
 and:
 safe.d(5):     `safe.f()`
 Failed: ["/usr/bin/dmd", "-v", "-o-", "safe.d", "-I."]
 ```


```d
--- x.d
import std.stdio;
extern(C) void f()  safe {
     writeln("Hello World!");
}
--- y.d
extern(C) void f()  trusted;

void main()
{
     f();
}
```

You can try it on run.dlang.io

Of course you can't overload `extern(C)` functions *in the same 
module,* but you can have a prototype in one module and the 
implementation in another. Marking non-`extern(D)` prototypes as 
` safe` should not be allowed and is frowned upon by me and 
others as the compiler has no safeguards against getting it 
wrong, i.e. having a ` system` implementation. For `extern(D)`, 
attributes are part of mangling, so if you're getting those 
wrong, at least the linker errors.
Aug 14
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 8/6/24 02:54, Walter Bright wrote:

 On 7/30/2024 1:09 PM, Timon Gehr wrote:

 What is a characterization of those unattributed functions that are 
 the root cause for any lack of memory safety in unattributed 
 functions? Is it just `extern(C)` function prototypes? If so, that 
 seems a bit weird.


 
 Function prototypes can only be taken at face value. If they are 
 unattributed, they would be accepted as callable from  safe code.


That is not what the DIP says, and I think it is a really bad idea.


 Or we 
 could simply say that prototypes would have to be explicitly attributed 
 in order to be callable from  safe code.
 ...


That was my expectation from reading the DIP. My point was however more 
that unattributed functions will be perhaps not memory safe, but the 
only way to smuggle in something that is not memory safe in practice is 
via `extern(C)` prototypes, as all other checks appear to be present.

I think it is a bit weird to require `extern(C)` prototypes for this 
case of "unsafe unannotated". It would be better to be able to disable 
and enable safety checks in a more granular fashion.


 ...
 

 - there is still no way to enable safety checks in ` trusted` functions.


 
 One can always switch it temporarily to  safe, fix any errors, then put 
 it back.
 ...


One can actually not always do that. Think template instantiation.


 But in general, trusted code should be a very small part of a program.


` system` and ` trusted` code is where all the remaining memory safety 
accidents happen.

Basically, the issue is the lack of orthogonality between safety 
checking and interface safety. It does not hold that just because your 
interface is not safe, your implementation does not care about catching 
bugs. Supporting linting use cases is quite cheap, as the checks are in 
the compiler anyway.
Aug 13
prev sibling parent Leonardo <leotada523 gmail.com> writes:
On Monday, 29 July 2024 at 16:40:52 UTC, Walter Bright wrote:

 As discussed in this thread:

 https://www.digitalmars.com/d/archives/digitalmars/D/D_not_considered_memory_safe_374866.html

 [...]


I liked the Walter idea.
Aug 05