Obviously not, Fil-C doesn't prevent or claim to prevent all security issues in modern code either.

But the issues Fil-C prevents, it prevents in very old programs compiled with it , if they compile, just as much as current programs.

At compile time, certain patterns that are accepted in standard C are rejected by Fil-C, and the source code has to be changed if you still want to compile the program. At run time, Fil-C prevents memory-related security issues by reliably detecting invalid memory reads and writes that are usually part of an attack and producing deterministic behaviour, sometimes terminating the program, instead of letting the attacker take advantage of undefined behaviour that happens to compile to something the attacker can use. Both of those features work just as well with very old C programs as current ones.

I meant it in the sense of continuing to run old C code like X.org in a safer way without unnecessary rewrites to memory safe languages. These vulnerabilities, like this one that's been in the wild as you say for 30 years uncaught, will continue to be found. Something like Fil-C is really useful in that context.

I also said "would it have" -- I don't really care about timeline. Obviously Fil-C is a recent development, that doesn't make the question I asked any less interesting.

From HN guidelines:

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

Perhaps next time, resist the urge :)