dip1000 and preview in combine to cause extra safety errors
Steven Schveighoffer
schveiguy at gmail.com
Thu Jun 9 01:34:16 UTC 2022
On 6/8/22 8:44 PM, Ali Çehreli wrote:
> > -- except on
> > extern(C) interfaces to C code, which by definition is un- at safe
>
> I see it differently: extern(C) interfaces are @trusted but they can't
> be checked. (More below.)
>
> I was convinced (after having an email exchange with Walter) that unless
> we assumed extern(C) functions @safe, then nobody would bother marking
> their declarations as @trusted one-by-one. And whoever marked them as
> such, they would do it without actually auditing any source code.
>
> What have we gained by disapproving @safe-by-default? Nothing: C API
> would either not be called and be marked blindly as @trusted. I think
> this is more embarrassing than @safe-by-default C libraries.
>
> So, D's presumed embarrassment of "C functions are assumed @safe" was
> against both practicality and the truth: The truth is, we indeed "trust"
> C functions because we use C libraries all the time without reading
> their source code. This is the definition of trust. And that's why I say
> we chose wrong names around this topic.
You are missing the point.
```d
extern(C) void *malloc(size_t);
extern(C) void free(void *); // @safe?
void main() // @safe!
{
auto ptr = malloc(int.sizeof);
int *v = ((p) @trusted => cast(int*)p)(ptr);
free(v);
*v = 5; // @safe??!
}
```
See, you can trust malloc and free to have *valid* implementations
(read, they are memory safe as long as you obey their rules). But they
don't obey `@safe` rules. They can't, they aren't written in D, and they
aren't checked by D. There is no way to express the invariants that they
require, and there certainly isn't a way to *infer* those invariants
based on the types of the parameters.
Marking them `@safe` by default is a disaster. It is the complete and
utter destruction of memory safety in D. I can't stress this enough.
I wish Walter had not brought this up, because I don't think it's
fruitful to have this discussion again.
-Steve
More information about the Digitalmars-d
mailing list