Khi nào Hành vi không xác định trong C nhảy rào cản nhân quả

Một số trình biên dịch C siêu hiện đại sẽ suy luận rằng nếu một chương trình sẽ gọi Hành vi không xác định khi được cung cấp một số đầu vào nhất định, thì các đầu vào đó sẽ không bao giờ được nhận. Do đó, bất kỳ mã nào không liên quan trừ khi nhận được đầu vào như vậy có thể bị loại bỏ.

Một ví dụ đơn giản, được đưa ra:

void foo(uint32_t);

uint32_t rotateleft(uint_t value, uint32_t amount)
{
  return (value << amount) | (value >> (32-amount));
}

uint32_t blah(uint32_t x, uint32_t y)
{
  if (y != 0) foo(y);
  return rotateleft(x,y);
}

một trình biên dịch có thể suy ra rằng vì việc đánh giá value >> (32-amount)sẽ mang lại Hành vi không xác định khi amountbằng 0, nên hàm blahsẽ không bao giờ được gọi ybằng 0; foodo đó, cuộc gọi đến có thể được thực hiện vô điều kiện.

Từ những gì tôi có thể nói, triết lý này dường như đã bị bắt giữ vào khoảng năm 2010. Bằng chứng sớm nhất tôi thấy về nguồn gốc của nó bắt đầu từ năm 2009, và nó đã được ghi nhận trong tiêu chuẩn C11, trong đó nêu rõ rằng nếu Hành vi không xác định xảy ra ở bất kỳ điểm trong quá trình thực thi chương trình, hành vi của toàn bộ chương trình trở nên không xác định.

Được quan điểm cho rằng trình biên dịch nên cố gắng sử dụng hành vi undefined để biện minh cho việc tối ưu ngược nhân quả (tức là hành vi undefined trong rotateleftchức năng nên gây ra trình biên dịch cho rằng blahphải được gọi với một tổ chức phi-zero y, hay không bất cứ điều gì sẽ không bao giờ gây ra yđể giữ một giá trị khác không) được ủng hộ nghiêm túc trước năm 2009? Khi nào một điều như vậy lần đầu tiên được đề xuất nghiêm túc như là một kỹ thuật tối ưu hóa?

[Phụ lục]

Một số trình biên dịch, ngay cả trong Thế kỷ 20, bao gồm các tùy chọn để cho phép các loại suy luận nhất định về các vòng lặp và các giá trị được tính toán trong đó. Ví dụ, được đưa ra

int i; int total=0;
for (i=n; i>=0; i--)
{
  doSomething();
  total += i*1000;
}

một trình biên dịch, ngay cả khi không có các suy luận tùy chọn, có thể viết lại thành:

int i; int total=0; int x1000;
for (i=n, x1000=n*1000; i>0; i--, x1000-=1000)
{
  doSomething();
  total += x1000;
}

vì hành vi của mã đó sẽ khớp chính xác với bản gốc, ngay cả khi trình biên dịch đã chỉ định rằng intcác giá trị luôn bao bọc theo kiểu bổ sung của hai mod-65536 . Tùy chọn suy luận bổ sung sẽ cho phép trình biên dịch nhận ra rằng vì ivà x1000nên vượt qua 0 cùng một lúc, biến trước đây có thể được loại bỏ:

int total=0; int x1000;
for (x1000=n*1000; x1000 > 0; x1000-=1000)
{
  doSomething();
  total += x1000;
}

Trên một hệ thống có intcác giá trị được bao bọc mod 65536, một nỗ lực để chạy một trong hai vòng đầu tiên nbằng 33 sẽ dẫn đến doSomething()việc được gọi 33 lần. Ngược lại, vòng lặp cuối cùng sẽ không gọi được doSomething(), mặc dù lần gọi đầu tiên doSomething()sẽ có trước bất kỳ tràn số học nào. Một hành vi như vậy có thể được coi là "phi nhân quả", nhưng các tác động bị hạn chế một cách hợp lý và có nhiều trường hợp hành vi đó sẽ vô hại (trong trường hợp một hàm được yêu cầu để mang lại một số giá trị khi được đưa vào bất kỳ đầu vào nào , nhưng giá trị có thể tùy ý nếu đầu vào không hợp lệ, có vòng lặp kết thúc nhanh hơn khi được cung cấp giá trị không hợp lệ lànsẽ thực sự có lợi). Hơn nữa, tài liệu trình biên dịch có xu hướng xin lỗi vì thực tế là nó sẽ thay đổi hành vi của bất kỳ chương trình nào - ngay cả những chương trình tham gia vào UB.

Tôi quan tâm đến khi thái độ của các nhà biên dịch thay đổi khỏi ý tưởng rằng các nền tảng nên khi tài liệu thực tế có một số hạn chế về hành vi có thể sử dụng được ngay cả trong trường hợp không được Tiêu chuẩn bắt buộc, với ý tưởng rằng mọi cấu trúc sẽ dựa trên bất kỳ hành vi nào không được ủy quyền bởi Tiêu chuẩn phải được gắn nhãn bất hợp pháp ngay cả khi trên hầu hết các trình biên dịch hiện có, nó sẽ hoạt động tốt hoặc tốt hơn bất kỳ mã tuân thủ nghiêm ngặt nào đáp ứng các yêu cầu tương tự (thường cho phép tối ưu hóa không thể thực hiện được trong mã tuân thủ nghiêm ngặt).

Hành vi không xác định được sử dụng trong các tình huống không thể xác định cụ thể để chỉ định hành vi và nó luôn được viết để cho phép hoàn toàn mọi hành vi có thể.

Các quy tắc cực kỳ lỏng lẻo cho UB rất hữu ích khi bạn nghĩ về những gì một trình biên dịch tuân thủ thông số kỹ thuật phải trải qua. Bạn có thể có đủ mã hóa biên dịch để phát ra lỗi khi bạn thực hiện một số UB xấu trong một trường hợp, nhưng thêm một vài lớp đệ quy và bây giờ điều tốt nhất bạn có thể làm là một cảnh báo. Thông số kỹ thuật không có khái niệm về "cảnh báo", vì vậy nếu thông số kỹ thuật đã đưa ra một hành vi, nó sẽ phải là "một lỗi".

Lý do chúng ta thấy ngày càng nhiều tác dụng phụ của việc này là sự thúc đẩy để tối ưu hóa. Viết một spec tối ưu hóa phù hợp là khó. Viết một trình tối ưu hóa phù hợp với thông số kỹ thuật cũng có thể thực hiện một công việc tốt đáng kể để đoán những gì bạn dự định khi bạn đi ra ngoài thông số kỹ thuật là tàn bạo. Trình biên dịch sẽ dễ dàng hơn nhiều nếu họ giả sử UB có nghĩa là UB.

Điều này đặc biệt đúng với gcc, cố gắng hỗ trợ nhiều tập lệnh với cùng một trình biên dịch. Việc để UB mang lại các hành vi UB dễ dàng hơn nhiều so với việc cố gắng vật lộn với tất cả các cách mà mọi mã UB đơn lẻ có thể sai trên mọi nền tảng và đưa nó vào các cụm từ đầu của trình tối ưu hóa.

"Hành vi không xác định có thể khiến trình biên dịch viết lại mã" đã xảy ra trong một thời gian dài, trong tối ưu hóa vòng lặp.

Lấy một vòng lặp (ví dụ a và b là con trỏ để nhân đôi)

for (i = 0; i < n; ++i) a [i] = b [i];

Chúng tôi tăng một int, chúng tôi sao chép một phần tử mảng, chúng tôi so sánh với một giới hạn. Trình biên dịch tối ưu hóa trước tiên loại bỏ việc lập chỉ mục:

double* tmp1 = a;
double* tmp2 = b;
for (i = 0; i < n; ++i) *tmp1++ = *tmp2++;

Chúng tôi xóa trường hợp n <= 0:

i = 0;
if (n > 0) {
    double* tmp1 = a;
    double* tmp2 = b;
    for (; i < n; ++i) *tmp1++ = *tmp2++;
}

Bây giờ chúng ta loại bỏ biến i:

i = 0;
if (n > 0) {
    double* tmp1 = a;
    double* tmp2 = b;
    double* limit = tmp1 + n;
    for (; tmp1 != limit; tmp1++, tmp2++) *tmp1 = *tmp2;
    i = n;
}

Bây giờ nếu n = 2 ^ 29 trên hệ thống 32 bit hoặc 2 ^ 61 trên hệ thống 64 bit, trên các triển khai điển hình, chúng tôi sẽ có giới hạn tmp1 == và không có mã nào được thực thi. Bây giờ thay thế bài tập bằng một cái gì đó mất nhiều thời gian để mã gốc sẽ không bao giờ gặp sự cố không thể tránh khỏi vì mất quá nhiều thời gian và trình biên dịch đã thay đổi mã.

Nó luôn luôn là trường hợp trong C và C ++ là kết quả của hành vi không xác định, bất cứ điều gì có thể xảy ra. Do đó, luôn có trường hợp trình biên dịch có thể đưa ra giả định rằng mã của bạn không gọi hành vi không xác định: Hoặc không có hành vi không xác định trong mã của bạn, thì giả định đó là chính xác. Hoặc có hành vi không xác định trong mã của bạn, sau đó bất cứ điều gì xảy ra do giả định không chính xác được bao phủ bởi " bất cứ điều gì cũng có thể xảy ra".

Nếu bạn nhìn vào tính năng "hạn chế" trong C, toàn bộ điểm của tính năng là trình biên dịch có thể cho rằng không có hành vi không xác định, vì vậy chúng tôi đã đạt đến điểm mà trình biên dịch không chỉ có thể mà thực sự nên cho rằng không có không xác định hành vi.

Trong ví dụ mà bạn đưa ra, các hướng dẫn trình biên dịch thường được sử dụng trên các máy tính dựa trên x86 để thực hiện dịch chuyển trái hoặc phải sẽ thay đổi 0 bit nếu số lượng dịch chuyển là 32 cho mã 32 bit hoặc 64 cho mã 64 bit. Điều này trong hầu hết các trường hợp thực tế sẽ dẫn đến kết quả không mong muốn (ví dụ, và kết quả không giống như trên ARM hoặc PowerPC), vì vậy trình biên dịch hoàn toàn hợp lý khi cho rằng loại hành vi không xác định này không xảy ra. Bạn có thể thay đổi mã của bạn thành

uint32_t rotateleft(uint_t value, uint32_t amount)
{
   return amount == 0 ? value : (value << amount) | (value >> (32-amount));
}

và đề xuất với các nhà phát triển gcc hoặc Clang rằng trên hầu hết các bộ xử lý, mã "số tiền == 0" sẽ bị xóa bởi trình biên dịch, bởi vì mã trình biên dịch được tạo cho mã dịch chuyển sẽ tạo ra kết quả tương tự như giá trị khi số tiền == 0.

Điều này là do có một lỗi trong mã của bạn:

uint32_t blah(uint32_t x, uint32_t y)
{
    if (y != 0) 
    {
        foo(y);
        return x; ////// missing return here //////
    }
    return rotateleft(x, y);
}

Nói cách khác, nó chỉ nhảy rào cản nhân quả nếu trình biên dịch thấy rằng, với một số đầu vào nhất định, bạn đang gọi hành vi không xác định vượt quá nghi ngờ .

Bằng cách quay lại ngay trước khi gọi hành vi không xác định, bạn nói với trình biên dịch rằng bạn có ý thức ngăn chặn hành vi không xác định đó thực thi và trình biên dịch thừa nhận điều đó.

Nói cách khác, khi bạn có một trình biên dịch cố gắng thực thi đặc tả theo một cách rất nghiêm ngặt, bạn phải thực hiện mọi xác thực đối số có thể có trong mã của mình. Hơn nữa, các xác nhận này phải xảy ra trước khi gọi hành vi không xác định nói trên.

Chờ đợi! Và còn nhiều hơn thế!

Bây giờ, với các trình biên dịch thực hiện những điều siêu điên rồ nhưng siêu logic này, bạn bắt buộc phải nói với trình biên dịch rằng một hàm không được phép tiếp tục thực thi. Vì vậy, noreturntừ khóa trên foo()chức năng bây giờ trở thành bắt buộc .