SDBG64 shows wrong attributes of undefined array argument

The test program below passes an array as an input argument to a subroutine without having defined the array values. Compile with /64 /undef /link, and open the EXE with SDBG64.

Press F7 (or 'step in'), and the line with 's = 0' is reached. Now, try to obtain information regarding the array, by hovering the mouse pointer on 'fct' in Line-17 or in the Variables pane. You will see 'REAL*8 Array size not known', even though the array size is the integer parameter NH4, whose value is 25. With the mouse pointer on 'fct' in Line-17, do right-click. You will see the puzzling message 'fct): Too many closing bracket' in the pop up that appears.

The same program, compiled in 32-bit mode with /undef /link and run in SDBG, does not have these problems. On the other hand, when F7 is pressed once and Line-15 is reached, the variables display now shows both FCT and FACT, even though the latter is not in scope.

I used FTN95 V 8.10.

module swmol_data
   implicit none
   integer, parameter :: dp = kind(0d0)
   integer, parameter :: NH4 = 25
   real(dp), dimension(NH4) :: fact
end module

subroutine excoef(fct,s)
   use swmol_data, only : dp, NH4
   implicit none
   real(dp), intent(in) :: fct(NH4)
   real(dp), intent(out) :: s
   integer i
!
   s = 0              ! note: fct() is undefined
   do i=1, NH4
      s=s+fct(i)
   end do
   return
end subroutine excoef

program xfact
   use swmol_data
   implicit none
   real(dp) :: s
!
   call excoef(fact,s)
   print *,s
   stop
end program

I reproduced the problem with FTN95 Ver 8.20 (I must install 8.30!)

I am not a frequent user of SDBG, but I do wonder:

1. Why can't I get info on parameters, like NH4, when I right click on them ? When looking at a longer code listing, the 'integer' definition is not always visible.
2. Why is there SDBG and SDBG64 ? shouldn't SDBG be able to identify what type of .exe file is being used. Both versions identified reference to undefined variable.

You have to compile with /FULL_DEBUG to generate OBJ files with full debugging information including PARAMETERs.

SDBG.EXE is 32-bit and will run on a PC with 32 or 64-bit version of Windows. SDBG64 is 64-bit and will not run on a 32-bit version of Windows. On 64-bit Windows, if either were to be launched with a mismatched target EXE, the debuggers could be made to detect the mismatch and relaunch the matching version of SDBG.

For me SDBG spawns SDBG64 when offered a 64 bit executable and SDBG64 spawns SDBG when offered a 32 bit executable.

/FULL_DEBUG is provided as a separate option otherwise you would get too many variables displayed when using standard INCLUDE files such as windows.ins.

Thanks mecej4 and Paul for the explanations

John

I suggest for a long time to show parameters with /debug. Developers definitely can make that all FTN95 own INS files containing WinAPI, OpenGL etc variables do not appear in the list of displayed variables similar to the options /73 which does not check these own INS files for violation of 72 character length

Dan

Yes developers could do that but the question is, how much work would be involved and how important is it? It's not a bug nor a missing facility. It just requires that users add a command line option.

However, I will make a note that this should be reviewed again.

I realise that making the changes that Dan suggested is probably low-priority, but here are my thoughts on how the implementation could be done to avoid clutter.

Since named constants are read-only, they need to be reviewed less often than variables. Unlike with true variables, one does not need to watch for changes in PARAMETERs. Therefore, PARAMETERs could be shown in their own PARAMETERS window instead of being merged into the other occupants of the VARIABLES window. The PARAMETERS window could remain hidden until the user requests that it be shown.

I think that it is ok that parameters are not listed in the variable window. However, when I hovered over a parameter name and right-clicked, could the parameter kind and value then be displayed ?

John, Yes, for me this would be also completely enough.