# Global variable initial value?

**URL:** <https://fortran-lang.discourse.group/t/global-variable-initial-value/3331>\
**Category:** Help\
**Created:** [April 27, 2022, 10:37am UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331 "2022-04-27T10:37:33Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![garynewport](https://avatars.discourse-cdn.com/v4/letter/g/898d66/32.png) [@garynewport](https://fortran-lang.discourse.group/u/garynewport)\
**Post date:** [April 27, 2022, 10:37am UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/1 "2022-04-27T10:37:33Z")

</div>

I have a variable defined within a module, called `unitz`.

I have a line early on in the code that states `kunitz = unitz` yet no where do I have an assigned value to `unitz`.

If I output the value of `unitz` at differing points within the code, even at the very start of the program, I am informed that `unitz` is equal to `0`.

Does Fortran default to zero for any variable defined?

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [April 27, 2022, 11:14am UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/2 "2022-04-27T11:14:04Z")

</div>

> [@garynewport](#):
>
> Does Fortran default to zero for any variable defined?

No, compilers may do so, and there are compiler flags specifically for this problem. But it is recommended to initialise all values manually:

```fortran
module test
    implicit none

    integer, save, public :: unitz = 0
end module test

```

---

<div class="post-metadata">

**Author:** ![garynewport](https://avatars.discourse-cdn.com/v4/letter/g/898d66/32.png) [@garynewport](https://fortran-lang.discourse.group/u/garynewport)\
**Post date:** [April 27, 2022, 1:09pm UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/3 "2022-04-27T13:09:40Z")

</div>

Thank you. I hasten to add that this is not originally my code and I am now exploring it in incredibly fine detail; hence finding this anomaly.

I am now trying to identify specifically what variables are required and what their initial values should be.

Thank you again.

---

<div class="post-metadata">

**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\
**Post date:** [April 27, 2022, 4:06pm UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/4 "2022-04-27T16:06:44Z")

</div>

Depending on the size of the code and the number of variables used in it, scanning the code for initializations can take an unacceptably long time. If so, use a compiler that provides facilities for trapping variables that are used before being initialized.

---

<div class="post-metadata">

**Author:** ![garynewport](https://avatars.discourse-cdn.com/v4/letter/g/898d66/32.png) [@garynewport](https://fortran-lang.discourse.group/u/garynewport)\
**Post date:** [April 27, 2022, 4:15pm UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/5 "2022-04-27T16:15:23Z")

</div>

My exact intention!

First, I need to work on the small element I am working on at present; since I got to the middle of it before finding this issue. 🙂

---

<div class="post-metadata">

**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\
**Post date:** [April 27, 2022, 8:00pm UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/6 "2022-04-27T20:00:21Z")

</div>

> [@interkosmos](#):
>
> ```auto
> module test
> implicit none
> 
> integer, save, public :: unitz = 0
> end module test
> 
> ```

`save` won’t hurt here but is _double unnecessary_

1. All variables in a module are automatically `save`d
2. Variables declared with initialization also acquire `save` attribute

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [April 27, 2022, 8:15pm UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/7 "2022-04-27T20:15:30Z")

</div>

Certainly, but it is a common pitfall in Fortran, and explicit is better than implicit.

---

<div class="post-metadata">

**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\
**Post date:** [April 27, 2022, 8:19pm UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/8 "2022-04-27T20:19:28Z")

</div>

> [@mecej4](#):
>
> Depending on the size of the code and the number of variables used in it, scanning the code for initializations can take an unacceptably long time. If so, use a compiler that provides facilities for trapping variables that are used before being initialized.

I am planning to tweet the following:

> To catch the use of uninitialized variables, initialize real variables  
> to signalling NaN and integers to -999 and trap NaNs at run time with
> 
> gfortran -ffpe-trap=invalid,overflow -finit-real=snan -finit-integer=-999 -fbacktrace a.f90
> 
> Also see [Detection of Uninitialized Floating-Point Variables in Intel® Fortran](https://www.intel.com/content/www/us/en/developer/articles/technical/detection-of-uninitialized-floating-point-variables-in-intel-fortran.html).

If the code a.f90 is

```auto
program main
implicit none
integer :: i
real :: x(2)
print*,i
print*,sum(x)
end program main

```

compiling on WSL2 with the gfortran command above gives at run time

```auto
        -999

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0 0x7fdda118d700 in ???
#1 0x7fdda118c8a5 in ???
#2 0x7fdda0fc020f in ???
#3 0x55a02f2b2287 in MAIN__
#4 0x55a02f2b2302 in main
Floating point exception

```

and something similar on Windows.

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [April 27, 2022, 10:35pm UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/9 "2022-04-27T22:35:05Z")

</div>

The NAG compiler (nagfor) has an option `-C=undefined` that does extensive run-time checking for uses of uninitialized variables. It has a couple of caveats (no inter-operating with C and no coarray features), and a few bugs I’ve been reporting, but I’ve found it quite helpful in finding some subtle bugs even beyond your run-of-the-mill oops.

---

<div class="post-metadata">

**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\
**Post date:** [April 28, 2022, 12:11am UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/10 "2022-04-28T00:11:20Z")

</div>

You might want to add -g so you get symbol names on tracebacks, and mention  
-Wuninitialized on gfortran, particularly making note that -Wuninitialized and -finit-real=snan are mutually exclusive (well, actually I think using -finit-real=snan defines variables so -Wuninitialized has nothing left to find). A lot of users of gfortran just do “man gfortran” or “gfortran --help” and often are not aware of the many other options available, many of which are displayed with “gfortran -v --help”, so it is easy to miss options llike -Wuninitialized, as it does not show with a simple “gfortran --help”. When we used to make local compiler changes we always set negative indefinite as the default where available, and use to create a universal config file for the Intel compiler to help detect uninitialized variables; particularly since we had a number of codes that had originated on VAX/VMS where (if I remember correctly) the Fortran compiler initialized everything to zero; so I am all for users using those options during development; but if you have large arrays there can be a significant cost to initializing them that you might want to avoid in a production release.

A footnote. There seems to be a regresssion on a bug reported long ago with -Wuninitialized and I/O. If you do a “gfortran -Wuninitialized” on

```fortran
program testit
   a=a+1
end program testit

```

it produces a warning, but

```fortran
program testit
   write(*,*)a
   a=a+1
end program testit

```

produces no warning. Thought that was fixed a VERY long time ago.

---

<div class="post-metadata">

**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\
**Post date:** [April 28, 2022, 12:14pm UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/11 "2022-04-28T12:14:53Z")

</div>

Re presence of I/O statement causing failure to detect uninitialized variable:

> [@urbanjost](#):
>
> Thought that was fixed a VERY long time ago

I do not know which Gfortran bug ID you refer to, but there is one [still active bug report](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34721), and the test code in it is very similar to your example.

---

<div class="post-metadata">

**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\
**Post date:** [April 28, 2022, 12:23pm UTC](https://fortran-lang.discourse.group/t/global-variable-initial-value/3331/12 "2022-04-28T12:23:07Z")

</div>

That one covers it. The bug I was referring to is not that incorrect executables are generated, but that the -Wuninitialized option does not warn about uninitialized variables that appear in I/O statements; which your link reports. Thanks for the link; that saves me from searching for/reporting the same bug.
