Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

[Dukc]

On Sunday, 6 December 2020 at 04:52:19 UTC, Bruce Carneal wrote:
> Even though I love working on projects that should operate near 
> HW limits, I would like to see defaults favor newcomers and 
> prototyping (@safe, throw, gc).
>
> 1028 without the "C is @safe" falsehood could work.

Consider a module with `@safe:` or `@trusted:` at top. The 
problem with the rule "external C functions can't be @safe" or 
"can't be @safe by default" is that you do not know why the 
annotation is at the top of module. It could be because it has 
been reviewed, or it could be just to get functions calling it to 
quickly work.

Theoretically, if C code is considered `@safe` by default, you 
can tell them from each other. No attributes: `@system`, but 
considered `@safe` for now, meaning you want to review the module 
in the near future. `@safe` or `@trusted`: someone has checked 
the module, nothing to worry about.

I don't think this is a good argument, because a comment about 
whether a review is done is so easy and recommended to add in any 
case. But then again, it should not make much difference. It is 
still better to greenwash the C headers as safe (with an 
appropriate comment about the hack) and use them from `@safe` 
code, than to mark all your code `@system`. At least you're 
checking the D code.

So I think that the issue has been exaggregated. Either way, it'd 
be progress from the current language.