Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

[Timon Gehr]

On 09.12.20 12:46, Dukc wrote:
> 
> It might have some benefit: If non-annotated C libraries are considered 
> `@safe`, it'll mean that not-so-quality code is using compromised 
> `@safe`. Bad. But if they are considered `@system`, not-so-quality code 
> will not be using `@safe` AT ALL. Even worse.

That's a bit like saying it's bad if products produced using slave 
labour don't get a fair trade label.

Anyway, extern(C) code that may corrupt memory is not even necessarily 
buggy, some C functions just have an unsafe interface. If you want the 
@safe checks make small @trusted wrappers around those functions so that 
the interface becomes safe and explicitly annotate those extern(C) 
functions whose interface you think is safe with @trusted.

And if you don't care about @safe, that's fine too. If someone wants to 
use your library from @safe code they can add the required annotations 
themselves and send you a pull request.

> 
> 
> Also it sure sucks that the compiler would do the wrong thing by default, but would the pragmatic downsides be even worse for the Common Sense option? I don't know, But I'm saying that 1: it's a judgement call, not anything absolute, 2: either way one could live with, and would be far from making `@safe` meaningless. 

I'm not really willing to debate the pragmatic upsides of encouraging 
dishonesty in a modular verification context. There are none.