You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The n_318 variable is allocated on the stack, never initialized, finally loaded to %0 (and used for further logic with disastrous effect). The result is random, and for a very long time it went unnoticed, until it started to fail regularly on Ubuntu 22, on which uninitialized variables seem to be populated with 0xff's. In effect a new execution path has started to be taken in the f90_str_cpy1() function which implements the fun = '?' assignment: a call to the memset() now occurs which results in the segfault.
One would argue whether this is a proper error. An argument that there is a problem with this Fortran code could be articulated. More elegant version may look like this:
program string_init
implicit none
integer, parameter :: n = 128
print *, fun(n)
contains
character(n) function fun(n)
implicit none
integer :: n
if (n .gt. 0) then
fun = '?'
end if
end function
end
In this light, it may appear that in the original program the string length was indeed never known. But this raises a question about n's visibility, because gfortran manages to backpropagate n to the returned type parameter and emits the code that doesn't fail.
EDIT: another possible rewrite of the original code that results in a correct IR:
program string_init
print *, fun(128)
contains
function fun(n)
character(n) :: fun
if (n .gt. 0) then
fun = '?'
else
fun = ''
end if
end function
end
...it's expressing the original intent of the author more closely. Yet there's no rule in Fortran which could force a programmer to be more specific.
The text was updated successfully, but these errors were encountered:
pawosm-arm
changed the title
Uninitialized stack during string initialization in function that returns a string of the parametrized length
Uninitialized stack variable during string initialization in a function that returns a string of the parametrized length
Jan 15, 2024
consider following code:
This will result in the following IR snippet:
The
n_318
variable is allocated on the stack, never initialized, finally loaded to%0
(and used for further logic with disastrous effect). The result is random, and for a very long time it went unnoticed, until it started to fail regularly on Ubuntu 22, on which uninitialized variables seem to be populated with 0xff's. In effect a new execution path has started to be taken in thef90_str_cpy1()
function which implements thefun = '?'
assignment: a call to thememset()
now occurs which results in the segfault.One would argue whether this is a proper error. An argument that there is a problem with this Fortran code could be articulated. More elegant version may look like this:
In this light, it may appear that in the original program the string length was indeed never known. But this raises a question about
n
's visibility, because gfortran manages to backpropagaten
to the returned type parameter and emits the code that doesn't fail.EDIT: another possible rewrite of the original code that results in a correct IR:
...it's expressing the original intent of the author more closely. Yet there's no rule in Fortran which could force a programmer to be more specific.
The text was updated successfully, but these errors were encountered: