# Most common run-time errors? **URL:** \ **Category:** Uncategorized\ **Created:** [March 1, 2026, 8:55pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755 "2026-03-01T20:55:58Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [March 1, 2026, 8:55pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/1 "2026-03-01T20:55:58Z")
What are the most common run-time errors in your programs? For me they are 1. Using `allocate` for a variable that is already allocated. 2. Using an `optional` variable that is not `present`. 3. Mismatched format string and output. (I should get in the habit of using the G edit descriptor.) 4. Out-of-bounds array access. I want to see if a tool can catch most common errors through static analysis. For (1) you could add `if (allocated(x)) deallocate (x)` before `allocate(x(…)` unless the static analyzer can prove that `x` has not been allocated. For (2) you could similarly add an `if (present(x))` guard. For (3), when the variables to be printed are scalars or arrays with fixed sizes, a tool could check for mismatched formats. ---
**Author:** ![davidpfister](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/davidpfister/32/3949_2.png) [@davidpfister](https://fortran-lang.discourse.group/u/davidpfister)\ **Post date:** [March 2, 2026, 8:17am UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/2 "2026-03-02T08:17:04Z")
In addition to what you listed already, here is what I usually encounter: - using unassociated pointers - size mismatched, espacially with string passed to procedures whose dummy argument has an explicite length (that may not cause run-time errors dependending on what garbage is in memory, but results can be surprising) - using `size` with unallocated array (ifort returns 0, gfortran returns 1). The safe version would be `merge(size(array), 0, allocated(array))`. - When forgetting that Fortran has no short-circuiting logic (corrected example) : - > if (s \<= len(string) .and. string(s:s) /= ‘!’) then > s = s + 1 > end if since both sides of the `.and.` will be evaluated, this will eventually cause an out-o-bound array access). That applies to `if`, `while` and `merge` constructs. ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [March 2, 2026, 8:48am UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/3 "2026-03-02T08:48:56Z")
> [@davidpfister](#): > > When forgetting that Fortran has no short-circuiting logic (e.g. `if (s <= len(string)) .and. string(s:s) /= ‘!’) then; s = s + 1; end if` It seems there’s an extra `)` in there, but that’s exactly how I envision short-circuit being introduced in the language eventually (Maybe in Fortran 2038 Epochalypse Edition?), that is: ```fortran if (s <= len(string)) .and. (string(s:s) /= ‘!’) then ... endif if (x < 0) .or. (use_default) then ... endif ``` Even though borrowing syntax from bash seems frowned upon, that avoids introducing the awkward-looking, and also possibly colliding, `.andthen.` and `.orelse.`. ---
**Author:** ![davidpfister](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/davidpfister/32/3949_2.png) [@davidpfister](https://fortran-lang.discourse.group/u/davidpfister)\ **Post date:** [March 2, 2026, 9:14am UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/4 "2026-03-02T09:14:51Z")
Indeed. Thank for spoting the mistake. I corrected the example. I was more thinking about `.andalso.` 😅, but the brace approach looks better. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [March 2, 2026, 11:29am UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/5 "2026-03-02T11:29:09Z")
> [@davidpfister](#): > > merge(size(array), 0, allocated(array)) That is not safe either. You should assume that merge will evaluate both `tsource` and `fsource`. You need to use an `if` block. Because I have had the same problem with `size` I [proposed](https://github.com/j3-fortran/fortran_proposals/issues/219) making the size of an unallocated array -1. Peter Klausler suggested instead defining a safe wrapper for `size` ```fortran module mySizeModule contains pure integer function mySize(x) class(*), dimension(..), intent(in), optional :: x mySize = -1 if (present(x)) mySize = size(x) end function end module use mySizeModule integer, allocatable :: a(:), b( allocate(a(10)) print *, mySize(a), mySize(b) end ``` A previous thread was [Size of an unallocated array](https://fortran-lang.discourse.group/t/size-of-an-unallocated-array/4633) ---
**Author:** ![feenberg](https://avatars.discourse-cdn.com/v4/letter/f/c2a13f/32.png) [@feenberg](https://fortran-lang.discourse.group/u/feenberg)\ **Post date:** [March 2, 2026, 11:38am UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/6 "2026-03-02T11:38:04Z")
I must not understand the OP, because the proposed solutions to 1 and 2 are both runtime checks, and since formats may be constructed at runtime, detecting format mismatch must also be a runtime check as well. But I approve of runtime checks. Maybe they can be disabled in a well understood inner loop, but in my work they are a trivial cost compared to debugging without them. The most common error I see that is not caught by gfortran is an uninitialized variable. Out-of-bounds array references are frequent, but caught by gfortran. ---
**Author:** ![davidpfister](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/davidpfister/32/3949_2.png) [@davidpfister](https://fortran-lang.discourse.group/u/davidpfister)\ **Post date:** [March 2, 2026, 12:43pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/7 "2026-03-02T12:43:18Z")
Thanks for the tip. Not sure I understand why it’s not safe, though. In that case, both sides can be evaluated, without any problem. But I would get the expected 0. I totally agree with you if you try to use `merge` with optional parameters, like `merge(1.0/x, 0.0, present(x))`. BTW, this could also be part of your checklist. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [March 2, 2026, 12:48pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/8 "2026-03-02T12:48:09Z")
You can construct a format string at run time, but in my codes and in most codes I see, format strings are usually literals or named constants known at compile time (or there are `format` statements also known at compile time). I have a Python [script](https://github.com/Beliavsky/Pure-Fortran/blob/main/xformat_mismatch.py) to find format mismatches that for ```fortran implicit none integer, parameter :: n = 3 real :: x = 2.1 integer :: m, i = 3, a(0), j(n) = 0 integer, allocatable :: k(:) real :: y(n) = 3.1 allocate (k(2), source=0) print "(*(i0),f0.4)", j, y print "(2i0, f0.4)", j, x print "(2i0, f0.4)", k, x print "(2i0)", i, x print "(i0, f0.4)", (j(m), y(m), m=1,n) print "(*(f0.4))", a end ``` that says for `python xformat_mismatch.py xformat.f90 --verbose` ```auto 3 format/type mismatch finding(s) in 1 file(s) (definite 3, possible 0). xformat.f90:8 program main [definite] - format descriptor 'i' likely mismatches item 2 type real xformat.f90:9 program main [definite] - format descriptor 'i' likely mismatches item 2 type real xformat.f90:11 program main [definite] - format descriptor 'i' likely mismatches item 2 type real ``` ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [March 2, 2026, 1:01pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/9 "2026-03-02T13:01:56Z")
> [@davidpfister](#): > > Not sure I understand why it’s not safe The standard states that the `ARRAY` argument of the `size` intrinsic… > shall be assumed-rank or an array. **It shall not be an unallocated allocatable variable** or a pointer that is not associated… So, `merge` may not crash the program with the compiler(s) you’re currently using, but in general the behavior is undefined. The ternary operator (i.e., `conditional-expression` in Fortran) was introduced to fix just that —it never evaluates the false branch. ---
**Author:** ![btrettel](https://avatars.discourse-cdn.com/v4/letter/b/5f9b8f/32.png) [@btrettel](https://fortran-lang.discourse.group/u/btrettel)\ **Post date:** [March 2, 2026, 2:08pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/10 "2026-03-02T14:08:27Z")
The thread so far discusses standard Fortran features causing errors, but I’ll bring up something non-standard that I wish was standard. I have my own `pure` assertion subroutine using `error stop`, which is pretty simple to create and common. Assertion violations are one of the most common categories of run-time errors for me. Conditions that I think (hope) are impossible happen sometimes, whether due to one or more bugs in my code or the condition itself being wrong. Most assertion violations can’t be found via static analysis. To find more assertion violations, people often propose fuzz testing, which I haven’t seen used on Fortran code yet. ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [March 2, 2026, 2:09pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/11 "2026-03-02T14:09:05Z")
> [@davidpfister](#): > > Not sure I understand why it’s not safe, though I’ve also complained in the past about the danger of using `size(x)` on unallocated `x` (this undefined behavior rule makes no sense to me - `size(x)` should just return `-1` on a non-allocated, allocatable argument, for the same reason that we can query the `allocated` status on it. Anyways if your array descriptor contains garbage (points to random address because unallocated), `size` may end up trying to read an unaccessible memory region, that can trigger a segfault on some systems/compilers. ---
**Author:** ![davidpfister](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/davidpfister/32/3949_2.png) [@davidpfister](https://fortran-lang.discourse.group/u/davidpfister)\ **Post date:** [March 2, 2026, 2:24pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/12 "2026-03-02T14:24:16Z")
Just tried that piece of code. I had no idea `present(b)`would return false if `b`is not allocated. Looks like black magic to me. ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [March 2, 2026, 2:37pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/13 "2026-03-02T14:37:43Z")
> [@FedericoPerini](#): > > this undefined behavior rule makes no sense to me I’ve always assumed it was for performance reasons… is that so? If one thinks in terms of DWARF, the size intrinsic would have to - Check if the argument is pointer/allocatable - If it is, fetch the corresponding allocation/association test - If allocated/associated, fetch the strides to compute the size By adding the restriction, two steps are saved. ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [March 2, 2026, 2:44pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/14 "2026-03-02T14:44:22Z")
The promised conditional-expression/conditional-argument also fixes that. Before, an unallocated or non-associated actual argument implied absence. Now (by which I mean, when widely implemented) you can use `.nil.` without the “has to be allocatable/pointer” restriction: ```fortran real :: x ... call f((x > 0 ? x : .nil.)) ``` ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [March 2, 2026, 2:44pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/15 "2026-03-02T14:44:26Z")
Defining `size(x)` to be -1 for x not `allocated` could allow some bad code to pass through. For example, If one sets `nsize_x_y = size(x) + size(y)` the result does not make sense if `size(x)` or `size(y)` is -1 because x or y is not allocated. It is better to get a run-time error in this case. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [March 2, 2026, 2:51pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/16 "2026-03-02T14:51:01Z")
> [@Beliavsky](#): > > Using `allocate` for a variable that is already allocated I proposed a few years ago to add an optional argument to ALLOCATE that tells the compiler if any of the arrays in an ALLOCATE list are already allocated, it is free to deallocate the array prior to reallocating to the new requested size. something like ```auto ALLOCATE(a(newsize), DEALLOCATE=.TRUE.) ``` Since most compilers already throw an hard error (absent the STAT option) then logic says that checking for an existing allocation already exists. Implementing this should not be a major task. Since this is a new option to an existing intrinsic there are no backwards compatability problems. This would save the additional logic required to check allocation first. I don’t usually have issues with any of your other problems since I make an extra effort (particularly the out of bounds access) during code development to make sure they don’t occur. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [March 2, 2026, 4:42pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/17 "2026-03-02T16:42:53Z")
> [@rwmsu](#): > > `ALLOCATE(a(newsize), DEALLOCATE=.TRUE.)` I also think this would be a good idea, but there are lots of details that must be considered. The reason this is important is that allocation is an expensive operation, particularly when done on the heap where it can trigger an expensive search or garbage collection operation, but even a local array allocated on the stack is expensive compared to, say, a few arithmetic operations. Those details involve what happens when 1) an array is already allocated with the correct size and bounds, and 2) the array is allocated with the correct size but with different bounds. That second situation involves simply changing the upper and lower bounds with given extents of an existing array, and also changing the extents and the bounds together for multidimensional arrays. For example, changing an existing (1:3,1:4) array of size 12 to a new (0:5,-2:-1) array using the same underlying allocation could be a very fast metadata operation rather than a slower heap/stack operation. This kind of operation, changing bounds and/or extents of allocated arrays, is not currently supported within the language, so there is a question of whether this should be a separate operation entirely, or whether it should be done within the more general ALLOCATE statement. So there are many possibilities that need to be considered to do this the right way within the language. If this is implemented in the standard, then all of the situations where an array is previously allocated need to be fully specified, in particular the situations where the array is a target of one or more pointers and whether those pointers retain their previous association status. We would want to avoid something like the current allocation-on-assignment situation where the pointer association status after an assignment statement is ambiguous or incomplete within the standard. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [March 2, 2026, 5:36pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/18 "2026-03-02T17:36:42Z")
> [@davidpfister](#): > > since both sides of the `.and.` will be evaluated, MAY be evaluated, and the order is unspecified. This can be a bigger problem if one of the operands is a function call - the program is not guaranteed to call the function if the processor can determine the value of the expression without doing so. ---
**Author:** ![davidpfister](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/davidpfister/32/3949_2.png) [@davidpfister](https://fortran-lang.discourse.group/u/davidpfister)\ **Post date:** [March 3, 2026, 5:52am UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/19 "2026-03-03T05:52:14Z")
Well, one more reason to avoid this kind of situation, I guess. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [March 3, 2026, 5:28pm UTC](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755/20 "2026-03-03T17:28:06Z")
> [@davidpfister](#): > > I had no idea `present(b)`would return false if `b`is not allocated. I think that works only for dummy arguments. In general, `present()` is not equivalent to `allocated()`. Its use in this way is limited to dummy arguments with the `optional` attribute but not the `allocatable` attribute that are associated with an unallocated actual argument. The standard considers this to be one of the cases where an optional dummy argument is not associated with an actual argument. [Next page](https://fortran-lang.discourse.group/t/most-common-run-time-errors/10755.md?page=2)