# Can I guarantee \`allocatable\` variables to start out not allocated? **URL:** \ **Category:** Help\ **Created:** [November 21, 2024, 5:13pm UTC](https://fortran-lang.discourse.group/t/can-i-guarantee-allocatable-variables-to-start-out-not-allocated/8865 "2024-11-21T17:13:03Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![adamyakes](https://avatars.discourse-cdn.com/v4/letter/a/d26b3c/32.png) [@adamyakes](https://fortran-lang.discourse.group/u/adamyakes)\ **Post date:** [November 21, 2024, 5:13pm UTC](https://fortran-lang.discourse.group/t/can-i-guarantee-allocatable-variables-to-start-out-not-allocated/8865/1 "2024-11-21T17:13:03Z")
In C#, if you want to indicate that an integer may or may not be there, you can mark it nullable, like this: ```cs int? x = null; ``` This is useful when you don’t have a value that’s “invalid”, like `0`, that lets you know the value isn’t there. In Fortran, marking a scalar `allocatable` achieves a similar result ```fortran integer, allocatable :: x ``` I know you can’t rely on local variables to have any value when declared. Is the same true for allocatable variables? My actual use-case involves an array of custom types: ```fortran type :: my_type real, allocatable :: ent real, allocatable :: lvg end type subroutine s(n) integer, intent(in) :: n type(my_type), allocatable :: arr(:) allocate(arr(n)) ! ... end subroutine ``` Can I count on all elements of `arr` to have unallocated `ent` and `lvg` variables? ---
**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:** [November 21, 2024, 6:51pm UTC](https://fortran-lang.discourse.group/t/can-i-guarantee-allocatable-variables-to-start-out-not-allocated/8865/2 "2024-11-21T18:51:33Z")
Yes, the language states that all allocatable variables and components have an initial status of unallocated. ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [November 22, 2024, 3:08pm UTC](https://fortran-lang.discourse.group/t/can-i-guarantee-allocatable-variables-to-start-out-not-allocated/8865/3 "2024-11-22T15:08:58Z")
You may find gfortran’s behavior surprising in this regard. You can bypass the surprise (allocated status upon second call) by explicitly deallocating the local allocatable objects before exiting the procedure. ---
**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:** [November 22, 2024, 5:01pm UTC](https://fortran-lang.discourse.group/t/can-i-guarantee-allocatable-variables-to-start-out-not-allocated/8865/4 "2024-11-22T17:01:35Z")
> [@shahmoradi](#): > > You may find gfortran’s behavior surprising in this regard. Which behavior are you referring to? The following ```fortran implicit none type :: my_type real, allocatable :: ent real, allocatable :: lvg end type call s(5) call s(6) contains subroutine s(n) integer, intent(in) :: n integer :: i type(my_type), allocatable :: arr(:) allocate (arr(n)) print*,'size(arr)=', size(arr) print*,(allocated(arr(i)%ent), allocated(arr(i)%lvg), i = 1, n) ! ... end subroutine end ``` Seems to work just fine: ```bash $ gfortran gfortran-alloc.f90 && ./a.out size(arr)= 5 F F F F F F F F F F size(arr)= 6 F F F F F F F F F F F F ``` ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [November 22, 2024, 5:17pm UTC](https://fortran-lang.discourse.group/t/can-i-guarantee-allocatable-variables-to-start-out-not-allocated/8865/5 "2024-11-22T17:17:18Z")
This is a relevant discussion: > [@Best practice: Deallocating allocatable arrays explicitly vs implicitly](https://fortran-lang.discourse.group/t/best-practice-deallocating-allocatable-arrays-explicitly-vs-implicitly/3071/8): > > I would only remind you that you do not get the choice of implicit deallocation in procedures when compiling with gfortran using heap arrays (gfortran -fmax-stack-var-size=10 main.f90 -o). To me, this seems to be a bug in gfortran. Intel ifort compiler has no issues with it. call testAutoDealloc call testAutoDealloc contains subroutine testAutoDealloc real, allocatable :: temp(slight_smile allocate(temp(200)) !deallocate(temp) end end Maybe the new gfortran has improved. ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [November 23, 2024, 8:24am UTC](https://fortran-lang.discourse.group/t/can-i-guarantee-allocatable-variables-to-start-out-not-allocated/8865/6 "2024-11-23T08:24:11Z")
I’ve come across the following question on StackOverflow, which may be related to the unexpected behavior of `allocatable` by Gfortran (linked in the above post, which is still reproducible with Gfortran-14 on Godbolt). Indeed, this may be a bug of the option `-fmax-stack-var-size` itself, though not sure about details. > EDIT: Here is the man page for this option. - [-fmax-stack-var-size](https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html#index-fmax-stack-var-size) > This option currently only affects local arrays declared with constant bounds, and may not apply to all character variables. Also a previous thread on this option (not related to the above issue): - [-frecursive .vs. fmax-stack-var-size .vs. -unlimit -s](https://fortran-lang.discourse.group/t/frecursive-vs-fmax-stack-var-size-vs-unlimit-s/2970)