안전한 프로그래밍 언어는 무엇입니까?

안전한 프로그래밍 언어 (PL)가 인기를 얻고 있습니다. 안전한 PL 의 공식적인 정의 가 무엇인지 궁금합니다 . 예를 들어, C는 안전하지 않지만 Java는 안전합니다. “safe”속성이 PL 자체가 아닌 PL 구현에 적용되어야한다고 생각합니다. 그렇다면 안전한 PL 구현의 정의에 대해 논의 해 봅시다. 이 개념을 공식화하려는 시도는 이상한 결과를 가져 왔으므로 다른 의견을 듣고 싶습니다. 모든 PL에 안전하지 않은 명령이 있다고 말하지 마십시오. 우리는 항상 안전한 부분 집합을 가질 수 있습니다.

우리 가 어떤면에서 언어를 "안전한" 것으로 부를 때 , 이는 공식적으로 언어로 구성된 프로그램이 우리가 위험한 것으로 생각하는 것을 할 수 없다는 증거가 있다는 것을 의미합니다. “안전”이라는 단어는 형식적으로도 덜 사용되지만 여기서 사람들은 귀하의 질문이 의미하는 바를 이해합니다. "안전한"언어에 원하는 속성에 대한 여러 가지 정의가 있습니다.

몇 가지 중요한 사항은 다음과 같습니다.

• Andrew Wright와 Matthias Felleisen의“type soundness”에 대한 정의는 위키피디아를 포함한 여러 곳에서“type safety”에 대한 허용 된 정의로 인용되며 1994 년 ML의 하위 집합이이를 충족 시킨다는 증거입니다.

• Michael Hicks 는 "메모리 안전"에 대한 몇 가지 정의를 여기에 나열합니다 . 일부는 발생할 수없는 오류 유형 목록이며 일부는 포인터를 기능으로 처리하는 데 기반합니다. Java unsafe는 가비지 수집기가 모든 할당 및 할당 취소를 관리 하도록하여 이러한 오류가 발생하지 않도록합니다 (표시된 기능을 명시 적으로 사용하지 않는 한 ). Rust는 unsafe아핀 타입 시스템을 통해 동일한 보증을한다 (코드를으로 명시 적으로 표시하지 않는 한 ), 최대 한 번 사용하기 전에 변수를 소유하거나 빌려야한다.

• 마찬가지로 스레드 안전 코드는 일반적으로 데이터 레이스 및 교착 상태를 포함하여 스레드 및 공유 메모리와 관련된 특정 종류의 버그를 나타낼 수없는 코드로 정의됩니다. 이러한 속성은 종종 언어 수준에서 시행됩니다. Rust는 유형 시스템에서 데이터 경쟁이 발생할 수 없음을 보장하고 C ++ std::shared_ptr은 여러 스레드에서 동일한 객체에 대한 스마트 포인터가 객체를 조기에 삭제하지 않거나 마지막 참조시 삭제하지 못하도록 보장합니다. C와 C ++ atomic는 언어에 내장 된 변수를 추가로 가지고 있으며 원자 연산은 올바르게 사용될 경우 특정 종류의 메모리 일관성을 보장합니다. MPI는 프로세스 간 통신을 명시 적 메시지로 제한하고 OpenMP에는 다른 스레드의 변수에 대한 액세스가 안전하도록 구문이 있습니다.

• 메모리가 누출되지 않는 특성을 종종 공간 안전이라고합니다. 자동 가비지 콜렉션은이를 보장하는 하나의 언어 기능입니다.

• 많은 언어는 그 작업이 잘 정의 된 결과를 가질 것이며 프로그램이 제대로 작동 할 것이라고 보증합니다. supercat이 위의 예를 제시 한 것처럼 C는 서명되지 않은 산술 연산 (안전하게 래핑되도록 보장됨)이지만 서명 된 산술 연산을하지 않습니다 (오버플로가 임의의 버그를 일으킬 수있는 경우) 그러나 언어는 때때로 부호없는 수량을 부호있는 수량으로 자동 변환합니다.

• 기능적 언어에는 예를 들어 순수한 기능이 부작용을 유발할 수없는 것과 같이 잘 구성된 프로그램이 유지하도록 보장되는 많은 변형이 있습니다. 이들은 "안전한"것으로 설명되거나 설명되지 않을 수 있습니다.

• SPARK 또는 OCaml과 같은 일부 언어는 프로그램 정확성을 입증하도록 설계되었습니다. 이것은 버그로부터 "안전한"것으로 설명되거나 설명되지 않을 수 있습니다.

• 시스템이 공식적인 보안 모델을 위반할 수 없다는 증거 (따라서“아마도 안전한 시스템은 아마 그렇지 않을 것입니다.”)

"안전한 프로그래밍 언어"에 대한 공식적인 정의는 없습니다. 비공식적 인 개념입니다. 오히려 안전을 제공한다고 주장하는 언어는 일반적으로 어떤 종류의 안전이 주장 / 보증 / 제공되는지에 대한 정확한 공식 진술을 제공합니다. 예를 들어, 언어는 유형 안전성, 메모리 안전성 또는 기타 유사한 보증을 제공 할 수 있습니다.

Benjamin Pierce의 Types and Programming Languages 사본을 손에 넣을 수 있다면 소개에서 "안전한 언어"라는 용어에 대한 다양한 관점에 대한 개요를 잘 볼 수 있습니다.

흥미로운 용어에 대한 제안 된 해석은 다음과 같습니다.

"안전한 언어는 프로그래머의 매뉴얼에 의해 완전히 정의됩니다."언어의 정의는 언어로 된 모든 프로그램의 동작을 예측하기 위해 프로그래머가 이해해야하는 일련의 일이되게하십시오. 그런 다음 C와 같은 언어에 대한 매뉴얼은 정의를 구성하지 않습니다. 특정 C 컴파일러가 메모리에 구조를 배치하는 방법에 대한 세부 사항을 알지 못하면 일부 프로그램 (예 : 검사되지 않은 배열 액세스 또는 포인터 산술 포함)의 동작을 예측할 수 없기 때문에 등으로, 동일한 프로그램은 다른 컴파일러에 의해 실행될 때 동작이 상당히 다를 수 있습니다.

따라서 프로그래밍 언어 구현을 지칭하기 위해 "안전하지 않은"이라는 용어를 사용하는 것이 주저합니다. 언어에서 정의되지 않은 용어가 다른 구현에서 다른 동작을 생성하는 경우 구현 중 하나에서 더 예상되는 제품 동작이 발생할 수 있지만 "안전한"이라고 부르지는 않습니다.

안전 은 이진이 아니며 연속체 입니다.

비공식적으로 말하면, 안전은 버그에 대한 반대이며, 가장 자주 언급되는 두 가지는 다음과 같습니다.

• 메모리 안전 : 언어 및 그 구현은 무 사용 후, 이중 프리, 범위를 벗어난 액세스 등과 같은 다양한 메모리 관련 오류를 방지합니다.
• 타입 안전 : 언어와 그 구현은 검사되지 않은 캐스트와 같은 다양한 타입 관련 오류를 방지합니다 ...

그것들은 언어가 예방 하는 유일한 버그 클래스 가 아니며 , 데이터 레이스 자유 또는 교착 상태 자유가 오히려 바람직하며, 정확성의 증거는 매우 달콤합니다.

단순히 잘못된 프로그램은 "안전하지 않은"것으로 간주되지 않으며 (버그만 해당), 안전이라는 용어는 일반적으로 프로그램에 대한 추론 능력에 영향을 미치기 위해 사용됩니다. 따라서 정의되지 않은 동작을 갖는 C, C ++ 또는 Go는 안전하지 않습니다.

물론, 안전하지 않은 부분 집합 (Java, Rust, ...)이있는 언어가 있으며 이는 개발자가 언어 보증을 유지해야하는 영역을 의도적으로 설명하고 컴파일러가 "핸드 오프"모드에 있습니다. 이 탈출구에도 불구하고 언어는 일반적으로 안전하다고 불리며 실용적인 정의입니다.

DW의 답변에 동의하지 않지만 "안전한"부분 중 하나는 해결되지 않은 것으로 생각합니다.

언급 한 바와 같이 여러 유형의 안전이 촉진됩니다. 왜 여러 개념이 있는지 이해하는 것이 좋습니다. 각 개념은 프로그램이 특정 종류의 버그로 인해 어려움을 겪는다는 생각과 관련이 있으며, 언어가 프로그래머가 그렇게하지 못하도록 막 으면 프로그래머가 이러한 종류의 버그를 만들 수 없다는 생각과 관련이 있습니다.

따라서 이러한 서로 다른 개념은 서로 다른 버그 클래스를 가지므로 이러한 클래스는 상호 배타적이지 않으며 이러한 클래스가 모든 형태의 버그를 다루지 않습니다. DW의 두 가지 예를 들자면, 특정 메모리 위치에 특정 객체가 있는지 여부에 대한 질문은 유형 안전과 메모리 안전의 문제입니다.

"안전한 언어"에 대한 추가 비판은 위험한 것으로 간주되는 특정 구조를 금지하면 프로그래머가 대안을 생각 해낼 필요가 있다는 관찰에서 비롯됩니다. 경험적으로, 좋은 라이브러리는 안전을 더 잘 달성합니다. 이미 현장에서 테스트 된 코드를 사용하면 새로운 버그를 만들지 않아도됩니다.

C와 Java의 근본적인 차이점은 Java의 식별하기 쉬운 특정 기능 (예 : Unsafe네임 스페이스의 기능)을 피할 경우 "잘못된"기능을 포함하여 시도 할 수있는 모든 조치가 가능한 결과 범위가 제한된다는 것입니다. . 이것은 최소한 Unsafe네임 스페이스 를 사용하지 않고 Java로 할 수있는 일 을 제한하지만, 잘못된 프로그램 또는 더 중요한 것은 올바르게 처리 할 수있는 프로그램으로 인해 발생할 수있는 손상을 제한 할 수 있습니다. 유효한 파일이지만 특히 잘못된 파일로부터 보호되지는 않습니다.

전통적으로 C 컴파일러는 "정상적인"경우에 표준 정의 방식으로 많은 작업을 처리하는 반면 "환경의 특성"으로 많은 코너 사례를 처리합니다. 수치 오버플로가 발생했을 때 단락되고 화재를 포착 할 수있는 CPU를 사용하고 있고 CPU 캐치 화재가 발생하지 않도록하려면 수치 오버플로를 피하기 위해 코드를 작성해야합니다. 그러나 2를 보완하는 방식으로 값을 완벽하게 자르는 CPU를 사용하는 경우 그러한 자르기가 허용 가능한 동작을 초래하는 경우 오버플로를 피할 필요가 없었습니다.

현대 C는 한 단계 더 나아갑니다. 표준이 요구 사항을 부과하지 않는 수치 오버플로와 같은 행동을 자연스럽게 정의하는 플랫폼을 대상으로하더라도 프로그램의 한 부분에서의 오버플로는 프로그램의 다른 부분의 행동에 영향을 줄 수 있습니다 시간과 인과 관계에 구속되지 않는 임의의 방식으로 프로그램 예를 들어 다음과 같은 것을 고려하십시오.

 uint32_t test(uint16_t x)
 {
   if (x < 50000) foo(x);
   return x*x; // Note x will promote to "int" if that type is >16 bits.
 }

위와 같이 주어진 "현대"C 컴파일러는 x가 46340보다 크면 x * x 계산이 오버플로되므로 무조건 "foo"에 대한 호출을 수행 할 수 있다고 결론 지을 수 있습니다. x가 범위를 벗어난 경우 프로그램이 비정상적으로 종료되도록하는 것이 허용 가능하더라도,이 경우 함수가 범위를 벗어난 x로 foo ()를 호출하면 훨씬 더 큰 손상을 초래할 수 있습니다. 그 가능성 중 하나. 전통적인 C는 프로그래머와 기본 플랫폼이 제공하는 것 이상으로 안전 장치를 제공하지는 않지만 안전 장치가 예기치 않은 상황으로 인한 손상을 제한 할 수있게합니다. Modern C는 모든 것을 통제하는 데 100 % 효과적이지 않은 안전 장비를 우회합니다.

언어에는 여러 층의 정확성이 있습니다. 추상화를 늘리려면 다음을 수행하십시오.

• 오류가없는 프로그램은 거의 없습니다 (정확성을 입증 할 수있는 프로그램 만 해당). 다른 사람들은 이미 오류 억제 가 가장 구체적인 안전 측면 이라고 언급했습니다 . Java 및 .net과 같은 가상 머신에서 실행되는 언어는 일반적으로 이와 관련하여 더 안전합니다. 프로그램 오류는 일반적으로 정의 된 방식으로 차단되고 처리됩니다. ¹

• 다음 단계에서는 런타임이 아닌 컴파일 타임에 오류가 감지되어 언어가 더 안전 해집니다. 구문 적으로 올바른 프로그램은 의미 적으로 가능한 한 정확해야합니다. 물론 컴파일러는 큰 그림을 알 수 없으므로 세부 수준과 관련이 있습니다. 강력하고 표현적인 데이터 유형은이 수준에서 안전의 한 측면입니다. 언어가 특정 종류의 오류를 만들기가 어려워 야 한다고 말할 수 있습니다.(유형 오류, 범위를 벗어난 액세스, 초기화되지 않은 변수 등). 길이 정보를 전달하는 배열과 같은 런타임 유형 정보는 오류를 피합니다. 나는 대학에서 Ada 83을 프로그래밍했으며 컴파일 Ada 프로그램은 일반적으로 해당 C 프로그램보다 오류가 훨씬 적다는 것을 알았습니다. 명시 적 변환없이 할당 할 수없는 정수 유형을 사용자 정의 할 수있는 Ada의 기능 만 사용하십시오. 피트와 미터가 혼동되어 전체 우주선이 추락하여 Ada로 사소하게 피할 수있었습니다.

• 다음 단계에서 언어는 상용구 코드를 피하는 수단을 제공해야합니다. 자신의 컨테이너, 분류, 연결을 작성해야하거나 직접 작성해야하는 경우 string::trim()실수를 할 수 있습니다. 추상화 수준이 높아 지므로이 기준에는 언어의 표준 라이브러리뿐만 아니라 적절한 언어가 포함됩니다.

• 요즘 언어는 언어 수준에서 동시 프로그래밍을위한 수단을 제공해야합니다. 동시성은 어려우며 언어 지원 없이는 올바르게 수행하기가 불가능합니다.

• 언어는 모듈화 및 협업을위한 수단을 제공해야합니다. 위의 강력하고 정교한 사용자 정의 유형은 표현 API를 작성하는 데 도움이됩니다.

다소 직교 적으로 언어 정의는 이해하기 쉬워야합니다. 언어와 라이브러리는 잘 문서화되어야합니다. 문서가 잘못되거나 누락되면 프로그램이 잘못되거나 잘못됩니다.

모든 PL에 안전하지 않은 명령이 있다고 말하지 마십시오. 우리는 항상 안전한 부분 집합을 가질 수 있습니다.

내가 아는 모든 언어에는 (컴파일되어) 실행될 수있는 불법 프로그램을 작성하는 방법이 있습니다. 그리고 내가 아는 모든 언어에는 안전한 하위 집합이 있습니다. 그래서, 당신의 질문은 무엇입니까?

안전은 다차원적이고 주관적입니다.

일부 언어에는 "안전하지 않은"작업이 많이 있습니다. 다른 사람들은 그러한 작업이 적습니다. 일부 언어에서는 기본적으로 작업을 수행하는 방법이 안전하지 않습니다. 다른 경우에는 기본 방법이 안전합니다. 일부 언어에는 명시적인 "안전하지 않은"하위 집합이 있습니다. 다른 언어에서는 그러한 하위 집합이 전혀 없습니다.

일부 언어에서 "안전성"은 표준 라이브러리에서 제공하는 서비스 및 / 또는 메모리 액세스 위반이 어렵거나 불가능한 런타임 인 ​​메모리 안전만을 전적으로 의미합니다. 다른 언어에서 "안전"에는 스레드 안전이 명시 적으로 포함됩니다. 다른 언어에서 "안전"은 프로그램이 중단되지 않는다는 보장 (어떤 종류의 예외도 허용하지 않는 요구 사항 포함)을 나타냅니다. 마지막으로, 많은 언어에서 "안전성"은 형식 안전성을 의미합니다. 형식 시스템이 특정 방식으로 일관성이있는 경우 "소리"라고합니다 (실제로 Java 및 C #에는 완전히 사운드 형식 시스템이 없음).

그리고 일부 언어에서 "안전성"의 모든 다른 의미는 유형 안전의 하위 집합으로 간주됩니다 (예 : Rust 및 Pony는 유형 시스템의 속성을 통해 스레드 안전을 달성 함).

이 답변은 조금 더 넓습니다. 안전과 안전이라는 단어는 최근 수십 년 동안 영어를 사용하는 사회에서 정치적으로 지향 된 특정 부분에 의해 잘려서 공통 사용이 거의 정의되지 않았습니다. 그러나 기술적 인 주제에 대해서는 여전히 "안전성"및 "안전성"을 다음과 같이 정의하려고합니다. .
따라서 안전한 언어에는 특정 종류의 버그를 제한하는 장치가 있습니다. 물론 한계에는 불편 함이나 심지어 무능력이 있기 때문에 "안전하지 않은"언어로 인해 버그가 발생한다고 말하는 것은 아닙니다. 예를 들어, 포크에 안전 코르크가없고 수십 년 동안 많은 노력을 기울이지 않고 먹으면서 눈을 찌르지 않도록 관리했습니다. 코르크를 사용하여 소비했던 것보다 확실히 적은 노력. 따라서 안전성은 판단해야 할 비용이 따릅니다. (포크 포크는 스티브 마틴 캐릭터에 대한 참조입니다)