Securing tomorrow's software: the need for memory safety standards

Re:Securing tomorrow's software: the need for memory safety ... by pizlonator on Wednesday February 26, 2025 @10:00PM (#43190862)

> That's exactly the kind of thing that the boosters of all those previous efforts said. But somehow it never quite worked out.

No, they really didn't. Let's review some of the big cases.

- SafeC: not based on a mainstream C compiler, so can't handle gcc/clang extensions (Fil-C can). Had no story for threads or shared memory (Fil-C does). Hence, not really compatible.

- CCured: incompatible (cannot compile C code with it without making changes, or running their tool that tries to automate the changes - but even then, common C idioms like unions don't quite work). Didn't use a major C compiler,

- SoftBound: not totally memory safe (no attempt to provide safety for linking or function calls). But at least it's highly compatible.

I can list more examples. Fil-C is the first to get both compatibility and safety right.

[ Parent | on HN ]

Re:Securing tomorrow's software: the need for memory safety ... by lmm on Wednesday February 26, 2025 @11:58PM (#43191494)

> Fil-C is the first to get both compatibility and safety right.

Has any impartial third party reached that conclusion? Because honestly the way I remember it everyone says this kind of thing when it's their own project, a lot of the people behind these previous efforts were just as confident as you are.

[ Parent | on HN ]

Re:Securing tomorrow's software: the need for memory safety ... by pizlonator on Thursday February 27, 2025 @12:26AM (#43191615)

Not in any official capacity but it’s been looked at by other C compiler experts, other programming language experts, GC experts, and security experts. Folks who have looked at it deeply agree with those claims. And I hope they would have told me if they didn’t believe anything about my claims!

[ Parent | on HN ]