问题
[EDITORIAL: I have read this question but (while in hindsight it is ultimately related in the same way that every question here is related -- i.e., "Why do computers malfunction?") that answer is not the answer to my question. That question is asking why a standards body designed a specific feature into the language. And, the answer does not answer my question which is asking what have I missed in debugging this issue.]
QUESTION: Why does the output from this Fortran program (ExhaustiveListing.f08 + unicodeSupport.f08) shown below indicate that Fortran's DO WHILE has a major bug?
Here's the output followed by environment description and, finally, the source code of the two files in question:
UNEXPECTED OUTPUT
Hex is now: 2500H.
2500─
2501━
2502│
2503┃
2504┄
2505┅
2506┆
2507┇
2508┈
2509┉
250A┊
250B┋
250C┌
250D┍
250E┎
250F┏
Hex is now: 2510H.
Hex is now: 2520H.
Hex is now: 2530H.
Hex is now: 2540H.
Hex is now: 2550H.
Hex is now: 2560H.
Hex is now: 2570H.
RUN FINISHED; exit value 0; real time: 530ms; user: 0ms; system: 0ms
EXPECTED OUTPUT
I expected to have 16 lines of detail between each "Hex is now: xxxxH" line such as that printed between the 2500H and 2510H lines.
PREVIOUS ATTEMPTS TO RESOLVE ISSUE
This program is my attempt to resolve an issue in a much larger project. Having issues with that project (one such problem revolving around working with Unicode in Fortran), I created this project to isolate the Unicode issue. At first, I had the trivial unicodeSupport module combined in the same file as the main program. I removed it into its own file. No, it should not matter and -- it did not affect the outcome. This program is so plainly simple, I cannot see anything which I might be doing wrong. Hence, my coming to SO in hopes that new eyes discover my blunder. Else, it's time to file bug report with gFortran.
ENVIRONMENT
The environment that I'm working in is:
OS: Ubuntu 17.10
IDE: Netbeans 8.2
JDK: Oracle (build 1.8.0_161-b12)
COMPILER: gFortran 7.2.0
COMPILER FLAGS: -std=f2008ts -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans
theGeeko61: 4 decades developing in BASIC, Pascal, FORTRAN, C, Prolog, C++, Java, many others (sorted chronologically by the order in which I learned them)
ExhaustiveListing.f08
! File: ExhaustiveListing.f08
! Author: geeko
!
! Created on March 25, 2018, 7:05 PM
!
! ☐ U2610 ☑ U2611 ☒ U2612
! Use above symbols for indicating items to
! be tested (☐), and items which have either
! passed (☑) or failed (☒) testing.
!
SUBROUTINE displayLine(hex)
USE unicodeSupport
IMPLICIT NONE
INTEGER :: hex, counter=0, point
DO WHILE (counter < 16)
point = hex+counter
WRITE(*,'(Z4.4,A)') point, CHAR(INT(point), ucs4)
counter = counter+1
END DO
END SUBROUTINE
PROGRAM ExhaustiveListingOfUnicodeBoxDrawingChars ! ☒
USE ISO_FORTRAN_ENV
USE unicodeSupport
!!!!!USE testUnicodeSupport ! ☑
IMPLICIT NONE
INTEGER :: hex
open(output_unit, encoding='UTF-8')
hex = 9472
DO WHILE(hex<9600)
PRINT '(A,Z4.4,A)', "Hex is now: ", hex, "H."
CALL displayLine(hex) ! ☒
hex = hex+16
END DO
!!!!CALL performTest() ! ☑
END PROGRAM ExhaustiveListingOfUnicodeBoxDrawingChars
unicodeSupport.f08
! File: unicodeSupport.f08
! Author: geeko
!
! Created on March 25, 2018, 10:09 PM
!
MODULE unicodeSupport
INTEGER, PARAMETER :: ASCII = SELECTED_CHAR_KIND('ASCII')
INTEGER, PARAMETER :: UCS4 = SELECTED_CHAR_KIND('ISO_10646')
END MODULE unicodeSupport
回答1:
The variable counter declared here
INTEGER :: hex, counter=0, point
possesses the save attribute by virtue of having its value defined on the initialization line.
The second time you enter the subroutine, its value will be 16 and hence there will be no loop.
Remove =0 from the declaration line and write
counter = 0
afterwards.
来源：https://stackoverflow.com/questions/49486184/why-is-the-counter-variable-unexpectedly-increased-in-every-subroutine-call