라이스 정리 때문에 웹 브라우저 나 워드 프로세서 또는 운영 체제에서 버그를 잡는 프로그램을 작성할 수 없다는 말을 자주 들었습니다.
그러나 실제 운영 체제와 같은 실제 프로그램에 어느 정도까지 적용되는지는 확실하지 않습니다. 이러한 유형의 프로그램에는 튜링 완성도의 완전한 힘이 필요합니까? 이러한 응용 프로그램을 작성할 수있는 간단한 계산 모델 (예 : PR)이 있습니까? 그렇다면 프로그램의 정확성을 어느 정도까지 결정할 수 있습니까?
라이스 정리 때문에 웹 브라우저 나 워드 프로세서 또는 운영 체제에서 버그를 잡는 프로그램을 작성할 수 없다는 말을 자주 들었습니다.
그러나 실제 운영 체제와 같은 실제 프로그램에 어느 정도까지 적용되는지는 확실하지 않습니다. 이러한 유형의 프로그램에는 튜링 완성도의 완전한 힘이 필요합니까? 이러한 응용 프로그램을 작성할 수있는 간단한 계산 모델 (예 : PR)이 있습니까? 그렇다면 프로그램의 정확성을 어느 정도까지 결정할 수 있습니까?
답변:
확실히 버그를 잡는 프로그램을 작성할 수 있습니다. 프로그램을 작성하는 사람들이 많고 활발한 커뮤니티가 있습니다. 그러나 라이스 정리가 방해하는 것은 건전하고 완전한 버그 캐처를 작성하는 것입니다 (즉, 오 탐지없이 특정 클래스의 모든 버그를 포착).
즉, 계산 모델에 대한 순진한 제한은 실제로 프로그램 분석의 실용성을 향상시키는 데 크게 도움이되지는 않습니다. 그 이유는 while 루프를 돌려서 "거의 같은 것"을하는 프로그램을 얻을 수 있기 때문입니다
while P do
C
반복 상수가 큰 for-loops로 :
for i = 0 to BIGNUM do
if P then
C
else
break
이제이 프로그램에는 원시 재귀의 전체 강도가 필요하지 않습니다 (for 루프는 거대한 중첩 된 if-then-else 문으로 매크로 확장 될 수 있기 때문에). 그러나 대부분의 실제 경우에는 이전과 동일하게 작동합니다. 이론적으로 결정 가능성에 도움이됩니다. 프로그램은 전체이므로 프로그램을 실행하고 결과를 확인하여 질문에 대답 할 수 있습니다. 이것은 실제로 우리가 원하는 것이 아닙니다. 즉, 프로그램을 실행하는 것보다 빠르게 답변을 얻는 것입니다. 도입 된 인위적인 종료는 실제 프로그램 로직의 오류로 인해 버그가 발생하기 때문에 실제로 프로그램 분석에 실제로 도움이되지 않습니다. 전혀 건드리지 않았습니다.
운영 체제와 같은 실제 프로그램의 프로그램 정확성에 대해 질문 했으므로 seL4 프로젝트 ( journal , pdf , conference )에 관심이있을 수 있습니다 .
NICTA 팀은 Haskell의 추상 사양에 따라 구현 된 8700 라인의 C와 600 라인의 어셈블러로 구성된 3 세대 마이크로 커널을 사용했습니다. 그들은 구현이 사양을 엄격히 준수한다는 공식적인 기계 검사 증거 (Isabelle / HOL)를 제공했습니다. 따라서 그들의 프로그램에 버그가 없음을 증명합니다.
따라서 정지 문제와 마찬가지로 일반적으로 해결할 수는 없지만 일부 특정 인스턴스에서는 해결할 수 있습니다. 이 경우 임의의 C 코드에 버그가 없음을 증명할 수는 없지만 seL4 마이크로 커널의 경우에는 그렇게 할 수 있습니다.
당신이 묻는 질문은 실제로 상당히 다릅니다.
그러나 실제 운영 체제와 같은 실제 프로그램에 어느 정도까지 적용되는지는 확실하지 않습니다. 이러한 유형의 프로그램에는 튜링 완성도의 완전한 힘이 필요합니까?
계산 모델이 튜링 완료되는 데는 거의 걸리지 않습니다. 예를 들어, 카운터가 있는 다양한 모델은 튜링 머신을 시뮬레이션 할 수 있습니다. 소프트웨어에 임의로 조작 할 수있는 카운터가 두 개 이상 필요하다고 생각되면 Turing 완전한 언어를 사용하는 것입니다. 머신 정수는 선순위로 제한되지만 힙 할당 데이터 구조는 일반적으로 그렇지 않습니다. 소프트웨어에 목록, 트리 및 기타 동적으로 할당 된 데이터가 필요한 경우 Turing 완전한 언어를 사용하는 것입니다.
이러한 응용 프로그램을 작성할 수있는 간단한 계산 모델 (예 : PR)이 있습니까? 그렇다면 프로그램의 정확성을 어느 정도까지 결정할 수 있습니까?
소프트웨어의 임의의 속성을 확인하고 싶지 않다는 것을 인식하는 것이 중요합니다. 매우 구체적이고 좁은 속성 (버퍼 오버플로, 널 포인터 역 참조, 무한 루프 등)을 확인하면 소프트웨어의 품질과 유용성이 크게 향상됩니다. 이론적으로 이러한 문제는 여전히 결정 불가능합니다. 실제로 특정 속성에 초점을 맞추면 문제를 해결하기 위해 종종 활용할 수있는 프로그램 구조를 찾을 수 있습니다.
특히 원래 질문을 다음과 같이 수정할 수 있습니다.
비 Turing 완전한 모델에서 효율적으로 분석 할 수있는 소프트웨어의 추상화가 있습니까?
추상화는 원본 소프트웨어의 동작 및 많은 추가 동작을 포함하는 모델입니다. 튜링이 완전하지 않고 분석 할 수있는 1- 카운터 기계 또는 푸시 다운 시스템과 같은 모델이 있습니다. 자동화 된 도구를 사용한 프로그램 검증의 표준 접근법은 이러한 모델에서 추상화를 구성하고 알고리즘 적으로 확인하는 것입니다.
사람들이 하드웨어 나 소프트웨어의 정교한 속성에 관심을 갖는 응용 프로그램이 있습니다. 하드웨어 회사는 칩이 산술 알고리즘을 올바르게 구현하기를 원하고 자동차 및 항공 전자 회사는 인증 가능한 올바른 소프트웨어를 원합니다. 그것이 중요하다면 (훈련 된) 인간을 사용하는 것이 좋습니다.