[c++] 초기화되지 않은 지역 변수가 가장 빠른 난수 생성기입니까?

이를 명확하게 말하겠습니다 : 프로그램에서 정의되지 않은 동작을 호출하지 않습니다 . 결코 좋은 생각, 기간이 아닙니다. 이 규칙에는 예외가 있습니다. 예를 들어, offsetof 구현 하는 라이브러리 구현자인 경우 . 귀하의 사례가 그러한 예외에 해당되는 경우 이미 알고있을 것입니다. 이 경우 초기화되지 않은 자동 변수를 사용하는 것은 정의되지 않은 동작 입니다.

컴파일러는 정의되지 않은 동작에 대한 최적화를 통해 매우 공격적으로 바뀌 었으며 정의되지 않은 동작으로 인해 보안 결함이 발생하는 경우가 많이 있습니다. 가장 악명 높은 경우는 아마도 C ++ 컴파일 버그에 대한 답변 에서 언급 한 Linux 커널 null 포인터 검사 제거 입니까?정의되지 않은 동작에 대한 컴파일러 최적화는 유한 루프를 무한 루프로 바꿨습니다.

CERT의 위험한 최적화 및 인과 관계의 상실 ( 비디오 )을 읽을 수 있습니다 .

점점 더 컴파일러 작성자는 C 및 C ++ 프로그래밍 언어에서 정의되지 않은 동작을 활용하여 최적화를 향상시키고 있습니다.

종종 이러한 최적화는 개발자가 소스 코드에서 원인-효과 분석을 수행하는 능력, 즉 이전 결과에 대한 다운 스트림 결과의 종속성 분석을 방해합니다.

결과적으로 이러한 최적화는 소프트웨어의 인과 관계를 제거하고 소프트웨어 결함, 결함 및 취약점의 가능성을 높입니다.

특히 불확실한 값과 관련하여 C 표준 결함 보고서 451 : 초기화되지 않은 자동 변수의 불안정성으로 인해 일부 흥미로운 판독이 가능합니다. 아직 해결되지 않았지만 흔들리는 값 의 개념을 소개 합니다. 이는 값 의 결정 성이 프로그램을 통해 전파 될 수 있으며 프로그램의 다른 지점에서 다른 불확실한 값을 가질 수 있음을 의미합니다.

이런 일이 발생하는 예는 모르지만 지금은 배제 할 수 없습니다.

실제 결과, 예상 결과가 아님

임의의 값을 얻지 못할 수 있습니다. 컴파일러는 루프를 완전히 최적화 할 수 있습니다. 예를 들어,이 간단한 경우

void updateEffect(int  arr[20]){
    for(int i=0;i<20;i++){
        int r ;
        arr[i] = r ;
    }
}

clang은 그것을 멀리 최적화합니다 ( 살펴보십시오 ) :

updateEffect(int*):                     # @updateEffect(int*)
    retq

또는이 수정 된 경우와 같이 모두 0을 얻습니다.

void updateEffect(int  arr[20]){
    for(int i=0;i<20;i++){
        int r ;
        arr[i] = r%255 ;
    }
}

라이브보기 :

updateEffect(int*):                     # @updateEffect(int*)
    xorps   %xmm0, %xmm0
    movups  %xmm0, 64(%rdi)
    movups  %xmm0, 48(%rdi)
    movups  %xmm0, 32(%rdi)
    movups  %xmm0, 16(%rdi)
    movups  %xmm0, (%rdi)
    retq

이 두 경우 모두 완벽하게 수용 가능한 형태의 정의되지 않은 동작입니다.

우리가 Itanium에 있다면 트랩 값으로 끝날 수 있습니다 .

[…] 레지스터가 특별한 값이 아닌 값을 보유하는 경우, 몇 가지 명령을 제외하고 레지스터 트랩을 읽는다 […]

다른 중요한 메모

UB Canaries 프로젝트에 언급 된 gcc와 clang 의 차이 가 초기화되지 않은 메모리와 관련하여 정의되지 않은 동작을 어떻게 활용할 것인지에 대해 주목 하는 것이 흥미 롭습니다 . 기사 노트 ( 강조 광산 ) :

물론 우리는 그러한 기대는, 특정 컴파일러가해야 할 일이 무엇을 함께 할 수있는 언어 표준과는 아무런 모든 것을이 없다고 스스로 완전히 명확하게 할 필요가 컴파일러의 제공이 내키지 때문에 하나 악용하는 것을 UB 하거나 그들이 아직 악용하지 않았기 때문 입니다. 컴파일러 제공 업체의 실제 보증이 존재 하지 않는 한 아직 개발되지 않은 UB는 시한 폭탄이라고 말하고 싶습니다 .

Matthieu M.은 모든 C 프로그래머가 정의되지 않은 행동 # 2 / 3에 대해 알아야 할 사항도 지적합니다 . 그것은 다른 것들 중에서도 강조합니다 (내 것을 강조합니다 ).

실현하기 위해 중요하고 무서운 일이 있다는 것입니다 단지에 대한 어떤
정의되지 않은 동작을 기반으로 최적화 미래에 언제든지 버그 코드를 트리거하고 시작할 수 있습니다 . 인라인, 루프 언 롤링, 메모리 승격 및 기타 최적화는 계속 향상되고 있으며 기존 이유의 상당 부분은 위와 같은 2 차 최적화를 제공하는 것입니다.

나에게 이것은 컴파일러가 필연적으로 비난을 받기 때문에 부분적으로 불만족 스러우며 또한 C 코드의 거대한 몸체 가 폭발하기를 기다리는 지뢰 라는 것을 의미하기 때문 입니다.

완전성을 위해서 아마 구현 예를 들어, 잘 정의 된 정의되지 않은 동작을 선택할 수 있습니다 언급해야 GCC가 노동 조합을 통해 유형 말장난을 허용 하면서 C ++에서이 정의되지 않은 동작처럼 보인다 . 이 경우 구현시 문서화해야하며 일반적으로 이식성이 없습니다.

답변

#include <stdio.h>

notrandom()
{
        int r, g, b;

        printf("R=%d, G=%d, B=%d", r&255, g&255, b&255);
}

int main(int argc, char *argv[])
{
        int i;
        for (i = 0; i < 10; i++)
        {
                notrandom();
                printf("\n");
        }

        return 0;
}

R=0, G=19, B=0
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255

void updateEffect(){
    for(int i=0;i<1000;i++){
        int r;
        int g;
        int b;
        star[i].setColor(r%255,g%255,b%255);
        bool isVisible;
        star[i].setVisible(isVisible);
    }
}