View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Sat Apr 07, 2018 12:52 am Post subject: 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.
Code: | 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 |
|
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sat Apr 07, 2018 3:15 am Post subject: |
|
|
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. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Sat Apr 07, 2018 8:25 am Post subject: |
|
|
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.
Last edited by mecej4 on Sat Apr 07, 2018 9:53 am; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Sat Apr 07, 2018 8:43 am Post subject: |
|
|
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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sat Apr 07, 2018 9:52 am Post subject: |
|
|
Thanks mecej4 and Paul for the explanations
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Sat Apr 07, 2018 11:53 am Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Sat Apr 07, 2018 1:18 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Sat Apr 07, 2018 3:42 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sun Apr 08, 2018 2:34 am Post subject: |
|
|
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 ? |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Sun Apr 08, 2018 4:50 am Post subject: |
|
|
John, Yes, for me this would be also completely enough. |
|
Back to top |
|
|
|