the ideas of turning off the checks for release mode is exactly what makes a language memory unsafe. that workflow protects you from accidental problems but is pretty much useless against the sorts of buffer overflows etc that enable attacks. Your test suite doesn’t test every pathological edge case. if the compiler can’t prove that a check is unnecessary, there’s a pretty good chance it’s needed.
@oscardssmith yes, I think you are describing a different use case: security. To prevent malicious attacks, then you indeed cannot turn off checks. So you are describing the ReleaseSafe mode.
ReleaseSafe indeed has performance penalties. The most obvious one is bounds checking for arrays. Rust for example also has a runtime overhead and keeps bounds checking on all the time. The Rust compiler might be able to optimize out such checks in many cases, but not all cases. I think Fortran has traditionally not been used in the ReleaseSafe mode, but you can do it today with Fortran compilers: keep bounds checks and enable all optimizations. But I think that compilers have not been very optimized for this use case, so the optimizations of bounds checks might not be as good as Rust’s.
Security has to be discussed in the context of the goals of the system. Scientific problems require efficient use of the hardware, and that probably requires “unsafe” code. So-called “safe” code is code that can be mechanically proven to be free of dangling pointers (ie. Rust’s borrow checker implements this). There are many perfectly correct programs that make use of “unsafe” code, like circularly linked lists.
This is why I think these issues of memory safety are outside of the scope of Fortran proper; a well designed system should be robust to issues like this. This was Andrew Tannenbaum’s argument in this presentation at EuroBSD a few years back.
The issue of various software flaws that lead to vulnerabilities and exploits need to be addressed at multiple levels. First, at the application level, very close attention to expected inputs needs to be paid. The inputs to software can be thought of as a formal language, and the software is a recognizer for that language. The language theoretic security approach elaborates on this using computational theory. The security properties of any piece of software can only be verifiable if the input language is either regular or context free.
I recommend this presentation by Meredith Patterson:
At the OS level, any code that can be run in user space, should be. This is the principle of least authority, and violation of it is common practice among all widely implemented operating systems.
1 Like
Is this search query on Google still largely accurate today
“In 2025, Fortran’s lack of professional, industrial-grade security compared to Rust, C++, and Mojo stems from its focus on computational speed over memory safety and ecosystem security.
While Fortran’s specialized “no-aliasing” rule provides numerical performance benefits, it lacks the modern language constructs and infrastructure required for high-assurance cybersecurity.”
The Mojo community is developing Mojo - a new programming language we’ve been developing fairly recently.
Sounds like FUD to me. Fortran is used for the numerical, computationally intensive portions of a software system. I’d expect Fortran to be used for mostly trusted inputs. In the cases where it is not, you would need to resort to things like strict input validation and extensive fuzzing in testing, which doesn’t make it any worse than C or C++ at this point.
Perhaps the Fortran compiler experts can offer insight, but how are allocatable arrays implemented in Fortran? Do they use something C programmers call a memory arena or pool allocation?
To be honest I am not sure if Google scoured the ends of the internet entirely on that specific search query - “Calling Python from Fortran (not the other way around)”:
https://www.noahbrenowitz.com/post/calling-fortran-from-python/
Just curious, what is main advantages of being “memory safe”?
Do “memory safe” languages immune from so called “Heisenbug”? Heisenbug - Wikipedia
1 Like
The current fad is “memory safety” because there are questionable stats floating around that “70 percent of zero day exploits are related to memory safety.”
To be entirely fair, there are very good reasons to push development practices toward more formal methods of verifying correctness regarding memory. But there has also been a lot of nonsense used as marketing fodder.
Rust has been developed to permit the compiler to formally verify that a subset of correct programs do not contain invalid memory accesses. This can be at the expense of memory leaks, which are still considered “memory safe.” Unfortunately, much of the Rust standard library relies on routines that are unsafe. To address this, there is a project to formally verify the standard library known as RustBelt
It is based upon a formalism known as separation logic, which is used to reason about memory in imperative programs. A compiler known as CompCert, is a verified C compiler using this formalism AFAICT.
It would just take some effort to adapt the separation logic formalism to Fortran, if that is needed. Much of this might appear to be tangential (no pun intended) to the main goal of Fortran users to efficiently compute results to complicated scientific questions on massive data sets.
4 Likes