[Fortran] Check for ACTION specifier in OPEN statements

[kcooley-cvd]

The OPEN statement allows the ACTION specifier which can be READ, WRITE, OR READWRITE, analogous to INTENT(IN), INTENT(OUT), and INTENT(INOUT) respectively. The programmer knows how an opened file is to be used, and using a file connection in a way contrary to the ACTION will produce a runtime error. Adding a check that each OPEN includes an ACTION could therefore help reveal bugs where a file that is intended to be read-only is written to. This would improve code correctness and security.

It would be even better not to rely on the runtime error, and instead check that no WRITE statement is applied to a unit opened as ACTION='READ' and vice versa.

[alvrogd]

Hi @kcooley-cvd,

Thank you for your feedback on improving the Open Catalog!

We weren't aware of this trick, and it's certainly helpful for enhancing correctness and security aspects, as you described.

If you'd like, feel free to submit a PR proposing an entry for this new recommendation. You can use existing ones as a reference, and I've also included a few tips at the bottom of this message to help get started. In any case, if you'd prefer not to, no problem! We'll note this idea and keep the issue open until it's been added.

Thank you again for your contribution! :)

Steps for adding a new recommendation (click me)

1. Each recommendation resides in its own directory under Checks/. Create the directory and update the list of checks in the README.md at the root of the repository.

2. Add a README.md file that includes the following:

   • Title: ID (e.g., the next available PWR number) + Name of the recommendation.
   • Issue: A brief description (1-2 sentences) of how the discouraged practice impacts the code.
   • Actions: A brief explanation (1-2 sentences) of how to refactor the code from the discouraged to the encouraged practice.
   • Relevance: A more detailed explanation of why adopting the recommended practice is beneficial, expanding on the previous points.
   • Code examples: Include a before-and-after code example to illustrate the improvement.
   • References: Add links or references for further reading, if available.

3. Create standalone example and solution source files containing the code examples.

4. Optionally, include a benchmark demonstrating the before-and-after performance impact of the change. In cases like this, the expectation is that the performance of the code should not degrade.

For reference, feel free to check out previous PRs to see how these steps are implemented in practice. For example, this is the PR that added PWR075.

Naturally, don't hesitate to ask at any moment if you have any issues. We'll be glad to help :)