Discussion Thread: DIP 1028--Make @safe the Default--Final Review

Timon Gehr timon.gehr at gmx.ch
Sun Apr 5 19:22:59 UTC 2020


On 04.04.20 08:53, Walter Bright wrote:
> On 4/3/2020 2:06 PM, Steven Schveighoffer wrote:
>> I want to make sure you understand that we are not talking about 
>> extern(C) functions that are written in D.
> 
> I understand totally what you are talking about.
> 
> 
>> But what should absolutely not compile is:
>>
>> extern(C) int free(void *);
>>
>> void foo(int *ptr) // now inferred @safe
>> {
>>     free(ptr);
>> }
> 
> I understand your proposal. You want C functions without bodies to be 
> @system.
> 
> 
>> The fact that we cannot control where/how people define their 
>> prototypes means we have to be firm on this. They need to opt-in to 
>> @safe with extern(C), it cannot be default.
> 
> On the other hand, special cases like this tend to cause unexpected 
> problems in the future.

This is the special case! @safe is supposed to mean the compiler has 
verified this function to not cause memory corruption. Why should 
extern(C) functions be an exception to that rule?

Your are essentially saying something like: "why should pointer 
arithmetic be disallowed in @safe functions when there are other 
operations on pointers that are okay? This seems like a special case 
rule that will cause problems in the future."

> Experience pretty much guarantees it. It's 
> likely to be tricky to implement as well.
> ...

I really doubt that. It's a simple rule. The version that is easiest to 
implement is you simply disallow extern(C) functions without body to be 
marked @safe. It's a single `if` statement in an appropriate place.

> People remember simple rules. They don't remember rules with odd 
> exceptions to them, that always winds up with trouble and bug reports. 

I think you are the only one in this thread who considers this to be the 
odd exception instead of the general rule.

> Simple rules applied evenly lead to a compiler that works and is 
> reliable. I'm afraid the weight of all the special rules will crush D.
> 
> Now, as to what to do. I spent a few minutes and added `@system:` in to 
> the C headers in druntime for windows, posix, and linux. Done. I hope 
> someone else will do it for freebsd, etc., if not I'll go do that to.
> 
>  > is going to cause huge issues.
> 
> I doubt that for the simple reason that @system by default has not 
> caused huge issues.
> ...

That makes no sense at all. You are arguing in favor of _ at trusted_ by 
default! It should not even be _possible_ to mark an extern(C) function 
@safe, it has to be either @system or @trusted. The compiler does not do 
any checking here.

> The rule is simple:
> 
> "For a D module with a bunch of C declarations in it, start it with 
> `@system:`."
> ...

So it's memory safety by convention.

> It's not a hard rule to check. It's one line. D's C interface has always 
> relied on the user to get right. Recall that C doesn't do any name 
> mangling at all:
> 
>    ----- mylib.di
>      extern (C) int addOne(int i);
> 
>    ----- mylib.c
>      double addOne(double d) { return d + 1; }
> 
> 
> That'll link fine and yet fail at runtime. Oops! Calling it @system will 
> not help at all. If the C implementation is bad, there's not a damn 
> thing D can do about it, with or without @system. It's always going to 
> be this way.

Right. How can you claim that this is @safe code?


More information about the Digitalmars-d mailing list