컴파일러와 인터프리터에 버그가있을 수 있으며 사용자로서 버그를 처리하기 위해 무엇을 할 수 있습니까? [닫은]

컴파일러의 작업이 소스 코드를 기계 수준 코드로 본질적으로 변환하는 경우 컴파일러에 결함이있을 수 있습니다 (예 : 잘못된 "번역")?

통역사도 마찬가지입니다. 때로는 필요한 컨텐츠를 출력하지 못할 수 있습니까?

컴파일러 / 통역사의 버그에 대해 들어 본 적이 없지만 존재합니까?

예

상대적으로 성숙한 언어 보다 적극적으로 개발되는 언어에서 더 자주 찾는 경향이 있습니다 (따라서 자주 많은 변화가 보이지 않음). 아마도 대부분의 언어가 다양한 '단계'안정성으로 출시되는 이유 일 것입니다. 야간 빌드는 릴리스 후보 보다 안정적 일 가능성이 훨씬 낮습니다. 릴리스 후보 는 완전히 출시되고 적극적으로 사용되는 버전보다 안정적 일 가능성이 적습니다.

운 좋게도 대부분의 언어 (특히 오픈 소스 언어)에는 보고서를 제출할 수 있는 공개 버그 추적 시스템 이 있습니다.

내 경험상 Windows의 Scala에서 상당히 모호하지만 심각한 버그가 발생했습니다 . 결과를 버그 추적기에 제출했는데 문제가 상당히 빨리 해결되었습니다. 이 경우 언어 개발자는 오류 로그 출력에 유용한 메모를 포함 할 정도로 똑똑하여 내가 겪었던 것은 실제로 컴파일러 오류였으며 보고서를 제출할 위치를 알려주었습니다.

평신도의 말로 :

모든 프로그램에는 버그가있을 수 있습니다.

컴파일러는 프로그램입니다.

Ergo, 컴파일러는 버그를 가질 수 있습니다.

하드웨어에서도 버그가있을 수 있습니다. 유명한 예는 Pentium FDIV 버그 입니다. 의심 할 여지없이 컴파일러에 버그가있을 가능성이 있습니다.

컴파일러와 인터프리터도 소프트웨어이므로 다른 소프트웨어의 문제가 없습니다.

이것은 MSVC 11 (2012) 최신 컴파일러의 예제 이며 백엔드 테스트 방법에 대한 기사입니다 .

물론 컴파일러는 소프트웨어이기 때문입니다.

2005 년에 대기업을 위해 작성한 매우 중요한 소프트웨어에서 코드 조각이 실패했습니다. 회사가 수정하는데 수백만 달러가 들었 기 때문에 물론 큰 수사를 시작했습니다.

고맙게도 (내 관점에서)이 문제는 Delphi의 컴파일러 문제로 판명되었습니다. try finally 블록에서 함수의 반환 값이 삭제되어 호출자에게 절대적으로 임의의 결과가 반환되었습니다. 이것은 Borland에 의해 문서화되고 인정되었습니다.

.NET은 문자 그대로 수백 가지의 메모리 누수, 특히 초기 구현에서 잘 알려져 있습니다.

버그가없는 소프트웨어는 없다고 주장합니다. 컴파일러도 예외는 아닙니다. 그러나 그들은 대부분의 비즈니스 소프트웨어보다 철저하게 테스트되었으며 똑똑하고 비판적이며 논쟁적인 사람들이 소비하므로 그들의 실적은 실제로 전체적으로 꽤 좋았습니다.

버그뿐만 아니라 의도적 인 멀웨어도 있습니다.

Brian Kernighan이 원래 Unix C 컴파일러에 구현 한 "로그인"트로이 목마는 가장 잘 알려져 있습니다. http://cm.bell-labs.com/who/ken/trust.html 기사 에 이에 대한 배경 지식이 있습니다.

물론 다른 소프트웨어 컴파일러와 마찬가지로 버그가 있습니다. 예를 들어 gcc 버그 목록이 여기에 있습니다.

예.

또한 컴파일러뿐만 아니라 인터프리터 / 디버거 및 타사 소프트웨어 도구를 사용합니다.

현재 일부 타사 소프트웨어를 사용하고 있으며 일부 문제가 있습니다. 때로는 버그를 찾아서보고 해 주셔서 감사합니다. :)

그들 중 일부는 메모리 누수가 발생하여 충돌이 발생합니다. 여기서 중요한 질문은 타사 도구 또는 컴파일러에 응용 프로그램이 올바르게 작동하는지 버그가 있는지 확인하는 방법입니다.

컴파일러는 한 언어로 작성된 프로그램 (원본 언어)을 읽고 다른 언어 (대상 언어), 주로 기계 언어의 다른 동등한 프로그램으로 변환하는 프로그램입니다.

소스 언어 코드를 한 줄씩 스캔하는 여러 단계의 컴파일러가 있습니다. 소스 언어 코드에서 스캔 된 모든 키워드를 추적하는 기호 테이블이 있습니다.

1 단계 : Lexical Analyzer-소스 프로그램의 모든 문자를 읽고 토큰의 논리적 분리 (int, char, float, if-else, for, while 등)를 형성합니다.

2 단계 : 구문 분석기-토큰 스트림의 구조를 분석합니다. 접두사 / 접두사 등을 포함하는 표현식의 계층 적 구문 분석 (a = b + c * d)

3 단계 : 시맨틱 분석기-토큰 유형 (실수, 부동 소수점 등의 정수) 및 연산자 우선 순위 등과 같은 많은 것들.

4 단계 : 중간 코드 생성기-a = b + c * de (temp1 = c * d, temp2 = temp1 + b, temp3 = temp2-e)

5 단계 : 코드 최적화-
중복되는 다양한 분석 (제어 흐름, 데이터 흐름, 변환) : 중복 코드, 상수 전파, 부분 데드 코드, 공통 하위 표현, 루프 불변 코드

6 단계 : 코드 생성-레지스터에 값을 입력하는 대상 코드 (대부분 어셈블리 언어) 생성

이 모든 단계는 잘 작성된 프로그램 일 뿐이며 N 개의 결함이있을 수 있습니다.

물론 컴파일러는 단지 프로그램 일 뿐이며 저자도 바보입니다. :). 언어 사양조차도 버그가있을 수 있습니다. 예 : 의 C #의 foreach + + 람다 .

또는 파이썬에서 인터프리터의 버그 : evil ast를 컴파일하면 인터프리터가 충돌합니다 .

컴파일러 / 인터 피터에서 버그를보고 싶다면 PHP를보십시오. 정수 오버플로로 유명한 버그가 있습니다. 첫 번째 수정은에서 시작되었습니다 if (size > INT_MAX) return NULL;. 이야기의 계속 .