파일 리디렉션이나 파이프를 사용하여 명령을 제공하는 것이 항상 작동하는 것은 아닙니다.

comp.lang.fortran의 기여자:

한 가지 문제는 메인 루프의 위치인 것 같습니다.

  done = .false.
  do while (.not. done)

    call main_menu(command)
    call run_command(command, surf, options, done, ioerror)

  end do

"run_command"를 호출하십시오:

subroutine run_command(command, surf, options, done, ioerror)
  ...
  logical, intent(out) :: done
  integer, intent(inout) :: ioerror

gfortran은 "run_command"가 "done" 값을 사용하지 않기 때문에 실제로 "done = .false" 문을 실행하는 데 아무런 의미가 없다고 추측하는 것 같습니다. 그리고 "run_command"는 "quit" 명령을 확인하지 않는 한 인수 "done"을 실제로 아무 것도 설정하지 않기 때문에 메인 루프가 "done"을 확인하는 동안 "done"은 초기화되지 않은 상태로 유지됩니다. 때로는 거짓일 때도 있고, 쓰레기를 포함할 때도 있는데, 이 경우 참으로 평가되어 메인 루프가 일찍 종료됩니다.

"done"의 의도를 "inout"으로 변경하면 문제가 해결되는 것 같습니다.

run_command의 "select case" 문 앞에 "done"을 설정하는 것도 작동하는 것 같습니다.

  done = .false.

  select case (command)
  ...

내 생각에는 이것이 이 문제를 해결하는 올바른 방법이며 컴파일러의 동작은 나를 포함하여 우리 중 일부에게는 놀랍지만 실제로는 정확하다고 생각합니다.

valgrind가 이것을 찾는 데 도움을 주었습니다.

또 다른 포스터는 다음과 같습니다.

마찬가지로 다음 예는

type(options_type), intent(out) :: opt

menu.f90 파일에서 다음으로 변경되어야 합니다.

type(options_type), intent(inout) :: opt

또는 Intent(out)가 있는 인수는 서브루틴에 들어갈 때 정의되지 않고 반환하기 전에 서브루틴에서 값을 가져오지 않으면 정의되지 않은 상태로 유지되므로 Intent 절을 생략해야 합니다.

다른 제안에는 배열 경계를 확인하는 옵션 등을 사용한 컴파일 및 실행이 포함됩니다.

이전 버전의 gfortran(gfortran 7.x 및 8.x)을 사용하여 프로그램 컴파일을 시도했는데 모든 것이 잘 작동했습니다. 그러나 최신 버전의 gfortran(9.x 및 10.x)에는 여전히 이 문제가 있습니다. 그런데 gfortran 9.x와 10.x에서 발생하는 이상한 동작을 플래그를 추가하거나 프로그램을 컴파일할 때 해결했습니다 -Og.-O0

@RoboNerd의 답변은 처음에 이런 일이 발생하는 이유를 설명합니다.