Hacker News new | ask | show | jobs
by avadodin 6 hours ago
There is a difference between being probably safe and being provably safe.

Rust's unsafes are likely safe.

Assembly snippets in the Linux kernel are likely safe.

These statements have no bearing on whether the present asm block being compiled right now is actually for–a–fact safe.

When none of the instructions perform a memory access, that is a guarantee.

As a diagnostics tool, Fil-C finds issues that are rarely present on any code I work on. A large subset of the issues are C++–adjacent.

I still believe its ideas —if applied correctly— can secure systems where someone thought an object system hacked in a weekend in C belongs in the tool "all LLMs depend on" or whatever.

BTW I do hand–write general–purpose assembly that is not a straight–forward intrinsic–equivalent and early drafts are full of all sorts of memory and register bank safety bugs.

1 comments

Thanks for explaining, I understand the importance of memory safety but I don’t think it is relevant enough in inline assembly context to implement something like this.