Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

[Dukc]

On Wednesday, 9 December 2020 at 18:20:48 UTC, Timon Gehr wrote:
> On 09.12.20 16:42, Dukc wrote:
>> You're thinking `@safe` as a certificate.
>
> It is, that's why it's on the function signature and causes 
> function type incompatibility. `@safe` has an actual modular 
> meaning that is communicated to the caller; it's not supposed 
> to be just a collection of lint heuristics. It's supposed to 
> contain all memory-safety errors within `@trusted` functions.
>

I quess the stance on this is where the fundamental disagreement 
about C code default `@safe`ty lies. If one considers, even in 
internal code, that `@safe` and `@trusted` are always 
declarations that calling it can never corrupt memory unless 
there's a honest mistake in the implementation, your stance on 
this is perfectly sound.

But as it can also work as a limited down-and-dirty bug-finder, I 
really think we should consider it as a valid use case. While 
continuing to consider use as a certifying aid valid alike.