[avadodin]

Just don't add memory safety bugs is solid advice, but treating "asm" as C's "unsafe" keyword would void the memory safety guarantees in Fil-C.

I don't know how the author's proprietary LLM swarm handled the job but his stated approach sounds reasonable to me.

[ozgrakkurt]

> Just don't add memory safety bugs is solid advice, but treating "asm" as C's "unsafe" keyword would void the memory safety guarantees in Fil-C.

This doesn't sound right to me and I wrote a decent amount of inline assembly in C like C++ code.

Are you saying this because you had unexpected memory safety bugs in inline asm?

[avadodin]

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.

[ozgrakkurt]

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.