Tại thời điểm nào trong vòng lặp, tràn số nguyên trở thành hành vi không xác định?

Đây là một ví dụ để minh họa câu hỏi của tôi liên quan đến một số mã phức tạp hơn nhiều mà tôi không thể đăng ở đây.

#include <stdio.h>
int main()
{
    int a = 0;
    for (int i = 0; i < 3; i++)
    {
        printf("Hello\n");
        a = a + 1000000000;
    }
}

Chương trình này chứa hành vi không xác định trên nền tảng của tôi vì asẽ tràn trên vòng lặp thứ 3.

Điều đó làm cho toàn bộ chương trình có hành vi không xác định, hoặc chỉ sau khi tràn thực sự xảy ra ? Liệu trình biên dịch có thể giải quyết vấn đề a sẽ bị tràn để nó có thể khai báo toàn bộ vòng lặp là không xác định và không bận tâm chạy các printfs mặc dù tất cả chúng đều xảy ra trước khi tràn?

_{(Được gắn thẻ C và C ++ mặc dù khác nhau vì tôi muốn biết câu trả lời cho cả hai ngôn ngữ nếu chúng khác nhau.)}

Nếu bạn quan tâm đến một câu trả lời thuần túy lý thuyết, tiêu chuẩn C ++ cho phép hành vi không xác định để "du hành thời gian":

[intro.execution]/5: Một triển khai tuân thủ thực hiện một chương trình được định dạng tốt sẽ tạo ra cùng một hành vi có thể quan sát được như một trong những thực thi có thể có của phiên bản tương ứng của máy trừu tượng với cùng một chương trình và cùng một đầu vào. Tuy nhiên, nếu bất kỳ quá trình thực hiện nào như vậy chứa một thao tác không xác định, thì tiêu chuẩn này không đặt ra yêu cầu đối với việc triển khai thực hiện chương trình đó với đầu vào đó (ngay cả đối với các hoạt động trước thao tác không xác định đầu tiên)

Như vậy, nếu chương trình của bạn chứa hành vi không xác định, thì hành vi của toàn bộ chương trình của bạn là không xác định.

Đầu tiên, hãy để tôi sửa tiêu đề của câu hỏi này:

Hành vi không xác định không (cụ thể) thuộc lĩnh vực thực thi.

Hành vi không xác định ảnh hưởng đến tất cả các bước: biên dịch, liên kết, tải và thực thi.

Một số ví dụ để củng cố điều này, hãy nhớ rằng không có phần nào là đầy đủ:

• trình biên dịch có thể giả định rằng các phần mã chứa Hành vi không xác định không bao giờ được thực thi, và do đó giả sử các đường dẫn thực thi dẫn đến chúng là mã chết. Xem Những gì mọi lập trình viên C nên biết về hành vi không xác định của không ai khác ngoài Chris Lattner.
• trình liên kết có thể giả định rằng khi có nhiều định nghĩa về một ký hiệu yếu (được nhận dạng bằng tên), tất cả các định nghĩa đều giống hệt nhau nhờ Quy tắc một định nghĩa
• trình nạp (trong trường hợp bạn sử dụng thư viện động) cũng có thể giả định như vậy, do đó chọn ký hiệu đầu tiên mà nó tìm thấy; cái này thường (ab) dùng để chặn cuộc gọi bằng LD_PRELOADthủ thuật trên Unix
• việc thực thi có thể không thành công (SIGSEV) nếu bạn sử dụng con trỏ treo

Đây là điều rất đáng sợ về Hành vi không xác định: không thể dự đoán trước, hành vi chính xác nào sẽ xảy ra và dự đoán này phải được xem lại ở mỗi lần cập nhật chuỗi công cụ, hệ điều hành cơ bản, ...

Tôi khuyên bạn nên xem video này của Michael Spencer (Nhà phát triển LLVM): CppCon 2016: My Little Optimizer: Undefined Behavior is Magic .

Một trình biên dịch C hoặc C ++ tối ưu hóa tích cực nhắm mục tiêu 16 bit intsẽ biết rằng hành vi khi thêm 1000000000vào một intkiểu là không xác định .

Nó được phép theo một trong hai tiêu chuẩn để làm bất cứ điều gì nó muốn, có thể bao gồm việc xóa toàn bộ chương trình, rời đi int main(){}.

Nhưng những gì về ints lớn hơn ? Tôi không biết có trình biên dịch nào làm được điều này (và tôi không phải là chuyên gia về thiết kế trình biên dịch C và C ++), nhưng tôi tưởng tượng rằng đôi khi một trình biên dịch nhắm mục tiêu 32 bit inttrở lên sẽ tìm ra rằng vòng lặp là vô hạn ( ikhông thay đổi) và vì thế acuối cùng sẽ tràn. Vì vậy, một lần nữa, nó có thể tối ưu hóa kết quả đầu ra int main(){}. Điểm tôi đang cố gắng đưa ra ở đây là khi việc tối ưu hóa trình biên dịch ngày càng trở nên tích cực hơn, ngày càng có nhiều cấu trúc hành vi không xác định đang tự biểu hiện theo những cách không mong muốn.

Thực tế là vòng lặp của bạn là vô hạn bản thân nó không phải là không xác định vì bạn đang ghi vào đầu ra chuẩn trong thân vòng lặp.

Về mặt kỹ thuật, theo tiêu chuẩn C ++, nếu một chương trình chứa hành vi không xác định, hành vi của toàn bộ chương trình, ngay cả tại thời điểm biên dịch (trước khi chương trình được thực thi), là không xác định.

Trong thực tế, vì trình biên dịch có thể giả định (như một phần của tối ưu hóa) rằng tràn sẽ không xảy ra, ít nhất hành vi của chương trình ở lần lặp thứ ba của vòng lặp (giả sử là máy 32 bit) sẽ không được xác định, mặc dù có khả năng bạn sẽ nhận được kết quả chính xác trước lần lặp thứ ba. Tuy nhiên, vì hành vi của toàn bộ chương trình là không xác định về mặt kỹ thuật, nên không có gì ngăn chương trình tạo ra đầu ra hoàn toàn không chính xác (bao gồm cả không có đầu ra), gặp sự cố trong thời gian chạy tại bất kỳ thời điểm nào trong quá trình thực thi hoặc thậm chí không thể biên dịch hoàn toàn (vì hành vi không xác định kéo dài đến thời gian biên dịch).

Hành vi không xác định cung cấp cho trình biên dịch nhiều chỗ hơn để tối ưu hóa bởi vì chúng loại bỏ các giả định nhất định về những gì mã phải làm. Khi làm như vậy, các chương trình dựa trên các giả định liên quan đến hành vi không xác định sẽ không được đảm bảo hoạt động như mong đợi. Do đó, bạn không nên dựa vào bất kỳ hành vi cụ thể nào được coi là không xác định theo tiêu chuẩn C ++.

Để hiểu tại sao hành vi không xác định lại có thể 'du hành thời gian' như @TartanLlama đã nói một cách đầy đủ về nó , chúng ta hãy xem quy tắc 'as-if':

1.9 Thực hiện chương trình

¹ Các mô tả ngữ nghĩa trong tiêu chuẩn này xác định một máy trừu tượng không xác định được tham số hóa. Tiêu chuẩn này không yêu cầu về cấu trúc của việc triển khai phù hợp. Đặc biệt, họ không cần sao chép hoặc mô phỏng cấu trúc của máy trừu tượng. Thay vào đó, các triển khai tuân thủ được yêu cầu để mô phỏng (chỉ) hành vi có thể quan sát được của máy trừu tượng như được giải thích bên dưới.

Với điều này, chúng ta có thể xem chương trình như một 'hộp đen' với một đầu vào và một đầu ra. Đầu vào có thể là đầu vào của người dùng, tệp và nhiều thứ khác. Đầu ra là 'hành vi quan sát được' được đề cập trong tiêu chuẩn.

Tiêu chuẩn chỉ định nghĩa một ánh xạ giữa đầu vào và đầu ra, không có gì khác. Nó thực hiện điều này bằng cách mô tả một 'hộp đen ví dụ', nhưng nói rõ ràng rằng bất kỳ hộp đen nào khác có cùng một ánh xạ đều có giá trị như nhau. Điều này có nghĩa là nội dung của hộp đen không liên quan.

Với suy nghĩ này, sẽ không hợp lý nếu nói rằng hành vi không xác định xảy ra tại một thời điểm nhất định. Trong phần triển khai mẫu của hộp đen, chúng ta có thể nói nó xảy ra ở đâu và khi nào, nhưng hộp đen thực tế có thể là một cái gì đó hoàn toàn khác, vì vậy chúng ta không thể nói nó xảy ra ở đâu và khi nào nữa. Về mặt lý thuyết, một trình biên dịch chẳng hạn có thể quyết định liệt kê tất cả các đầu vào có thể có và tính toán trước các kết quả đầu ra. Sau đó, hành vi không xác định sẽ xảy ra trong quá trình biên dịch.

Hành vi không xác định là sự không tồn tại của một ánh xạ giữa đầu vào và đầu ra. Một chương trình có thể có hành vi không xác định đối với một số đầu vào, nhưng hành vi được xác định đối với hành vi khác. Khi đó, ánh xạ giữa đầu vào và đầu ra chỉ đơn giản là không đầy đủ; có đầu vào mà không tồn tại ánh xạ tới đầu ra.
Chương trình trong câu hỏi có hành vi không xác định cho bất kỳ đầu vào nào, vì vậy ánh xạ trống.

Giả sử intlà 32-bit, hành vi không xác định xảy ra ở lần lặp thứ ba. Vì vậy, nếu, ví dụ, nếu vòng lặp chỉ có thể truy cập có điều kiện hoặc có thể kết thúc có điều kiện trước lần lặp thứ ba, sẽ không có hành vi không xác định trừ khi thực sự đạt đến lần lặp thứ ba. Tuy nhiên, trong trường hợp có hành vi không xác định, tất cả đầu ra của chương trình là không xác định, bao gồm đầu ra là "trong quá khứ" liên quan đến việc gọi hành vi không xác định. Ví dụ: trong trường hợp của bạn, điều này có nghĩa là không có gì đảm bảo sẽ thấy 3 thông báo "Xin chào" trong đầu ra.

Câu trả lời của TartanLlama là đúng. Hành vi không xác định có thể xảy ra bất cứ lúc nào, ngay cả trong thời gian biên dịch. Điều này có vẻ vô lý, nhưng đó là một tính năng chính để cho phép trình biên dịch làm những gì họ cần làm. Không phải lúc nào cũng dễ dàng trở thành một trình biên dịch. Bạn phải làm chính xác những gì thông số cho biết, mọi lúc. Tuy nhiên, đôi khi rất khó để chứng minh rằng một hành vi cụ thể đang xảy ra. Nếu bạn còn nhớ vấn đề tạm dừng, thì việc phát triển phần mềm mà bạn không thể chứng minh liệu nó có hoàn thành hay đi vào một vòng lặp vô hạn khi được cung cấp một đầu vào cụ thể là điều khá nhỏ.

Chúng tôi có thể làm cho các trình biên dịch trở nên bi quan và liên tục biên dịch vì sợ rằng hướng dẫn tiếp theo có thể là một trong những vấn đề tạm dừng như các vấn đề, nhưng điều đó không hợp lý. Thay vào đó, chúng tôi cung cấp cho trình biên dịch một quyền: đối với các chủ đề "hành vi không xác định" này, chúng được giải phóng khỏi mọi trách nhiệm. Hành vi không xác định bao gồm tất cả các hành vi bất chính tinh vi đến mức chúng ta gặp khó khăn khi tách chúng ra khỏi các vấn đề ngăn chặn thực sự khó chịu và bất chính và không thể.

Có một ví dụ mà tôi thích đăng, mặc dù tôi thừa nhận rằng tôi đã mất nguồn, vì vậy tôi phải diễn giải lại. Đó là từ một phiên bản MySQL cụ thể. Trong MySQL, chúng có một bộ đệm tròn chứa đầy dữ liệu do người dùng cung cấp. Tất nhiên, họ muốn đảm bảo rằng dữ liệu không tràn bộ đệm, vì vậy họ đã kiểm tra:

if (currentPtr + numberOfNewChars > endOfBufferPtr) { doOverflowLogic(); }

Nó trông đủ lành mạnh. Tuy nhiên, nếu numberOfNewChars thực sự lớn và tràn thì sao? Sau đó, nó bao bọc xung quanh và trở thành một con trỏ nhỏ hơn endOfBufferPtr, vì vậy logic tràn sẽ không bao giờ được gọi. Vì vậy, họ đã thêm một kiểm tra thứ hai, trước đó:

if (currentPtr + numberOfNewChars < currentPtr) { detectWrapAround(); }

Có vẻ như bạn đã quan tâm đến lỗi tràn bộ đệm phải không? Tuy nhiên, một lỗi đã được gửi cho biết rằng bộ đệm này đã tràn trên một phiên bản Debian cụ thể! Điều tra cẩn thận cho thấy rằng phiên bản Debian này là phiên bản đầu tiên sử dụng phiên bản gcc đặc biệt xuất sắc. Trên phiên bản gcc này, trình biên dịch nhận ra rằng currentPtr + numberOfNewChars không bao giờ có thể là một con trỏ nhỏ hơn currentPtr bởi vì tràn cho con trỏ là hành vi không xác định! Điều đó là đủ để gcc tối ưu hóa toàn bộ quá trình kiểm tra, và đột nhiên bạn không được bảo vệ khỏi sự cố tràn bộ đệm mặc dù bạn đã viết mã để kiểm tra nó!

Đây là hành vi đặc biệt. Mọi thứ đều hợp pháp (mặc dù từ những gì tôi nghe được, gcc đã lùi lại sự thay đổi này trong phiên bản tiếp theo). Đó không phải là những gì tôi sẽ coi là hành vi trực quan, nhưng nếu bạn mở rộng trí tưởng tượng của mình một chút, thật dễ dàng để thấy một biến thể nhỏ của tình huống này có thể trở thành một vấn đề tạm dừng đối với trình biên dịch. Bởi vì điều này, những người viết thông số kỹ thuật đã đặt nó là "Hành vi không xác định" và tuyên bố rằng trình biên dịch hoàn toàn có thể làm bất cứ điều gì nó hài lòng.

Ngoài các câu trả lời lý thuyết, một quan sát thực tế cho thấy rằng trong một thời gian dài, các trình biên dịch đã áp dụng các phép biến đổi khác nhau trên các vòng lặp để giảm lượng công việc được thực hiện bên trong chúng. Ví dụ, đã cho:

for (int i=0; i<n; i++)
  foo[i] = i*scale;

một trình biên dịch có thể chuyển đổi nó thành:

int temp = 0;
for (int i=0; i<n; i++)
{
  foo[i] = temp;
  temp+=scale;
}

Do đó tiết kiệm một phép nhân với mỗi lần lặp vòng lặp. Một hình thức tối ưu hóa bổ sung, mà các trình biên dịch thích ứng với các mức độ tích cực khác nhau, sẽ biến điều đó thành:

if (n > 0)
{
  int temp1 = n*scale;
  int *temp2 = foo;
  do
  {
    temp1 -= scale;
    *temp2++ = temp1;
  } while(temp1);
}

Ngay cả trên các máy có vòng lặp im lặng khi tràn, điều đó có thể hoạt động sai nếu có một số nào đó nhỏ hơn n, khi nhân với tỷ lệ, sẽ cho kết quả là 0. Nó cũng có thể biến thành một vòng lặp vô tận nếu tỷ lệ được đọc từ bộ nhớ nhiều hơn một lần. đã thay đổi giá trị của nó một cách bất ngờ (trong bất kỳ trường hợp nào mà "scale" có thể thay đổi giữa vòng lặp mà không cần gọi UB, trình biên dịch sẽ không được phép thực hiện tối ưu hóa).

Mặc dù hầu hết các tối ưu hóa như vậy sẽ không gặp bất kỳ sự cố nào trong trường hợp nhân hai loại không dấu ngắn để mang lại giá trị nằm giữa INT_MAX + 1 và UINT_MAX, nhưng gcc có một số trường hợp mà phép nhân như vậy trong một vòng lặp có thể khiến vòng lặp thoát sớm . Tôi đã không nhận thấy các hành vi như vậy xuất phát từ các hướng dẫn so sánh trong mã được tạo, nhưng có thể quan sát được trong trường hợp trình biên dịch sử dụng tràn để suy ra rằng một vòng lặp có thể thực thi nhiều nhất 4 lần trở xuống; theo mặc định, nó không tạo ra cảnh báo trong trường hợp một số đầu vào sẽ gây ra UB và những đầu vào khác thì không, ngay cả khi các suy luận của nó khiến giới hạn trên của vòng lặp bị bỏ qua.

Hành vi không xác định, theo định nghĩa, là một vùng màu xám. Bạn chỉ đơn giản là không thể dự đoán nó sẽ làm gì hoặc sẽ không làm gì - đó là "hành vi không xác định" nghĩa là gì .

Từ thời xa xưa, các lập trình viên đã luôn cố gắng cứu vãn tàn dư của tính xác định từ một tình huống không xác định. Họ có một số mã mà họ thực sự muốn sử dụng, nhưng hóa ra là không xác định, vì vậy họ cố gắng tranh luận: "Tôi biết nó không xác định, nhưng chắc chắn rằng, tệ nhất là nó sẽ làm điều này hoặc điều này; nó sẽ không bao giờ làm điều đó . " Và đôi khi những lập luận này ít nhiều đúng - nhưng thường thì chúng sai. Và khi các trình biên dịch ngày càng thông minh hơn (hoặc, một số người có thể nói, lén lút và lén lút hơn), ranh giới của câu hỏi tiếp tục thay đổi.

Vì vậy, thực sự, nếu bạn muốn viết mã được đảm bảo hoạt động và sẽ tiếp tục hoạt động trong thời gian dài, chỉ có một lựa chọn: tránh hành vi không xác định bằng mọi giá. Quả thật, nếu bạn đâm vào nó, nó sẽ quay lại ám ảnh bạn.

Một điều mà ví dụ của bạn không xem xét là tối ưu hóa. ađược đặt trong vòng lặp nhưng không bao giờ được sử dụng và một trình tối ưu hóa có thể giải quyết vấn đề này. Do đó, việc loại bỏ ahoàn toàn hoàn toàn là hợp pháp đối với trình tối ưu hóa , và trong trường hợp đó, tất cả các hành vi không xác định sẽ biến mất như nạn nhân của boojum.

Tuy nhiên, tất nhiên bản thân điều này là không xác định, vì tối ưu hóa là không xác định. :)

Vì câu hỏi này được gắn thẻ kép C và C ++ nên tôi sẽ thử và giải quyết cả hai. C và C ++ có các cách tiếp cận khác nhau ở đây.

Trong C, việc triển khai phải có khả năng chứng minh hành vi không xác định sẽ được gọi để xử lý toàn bộ chương trình như thể nó có hành vi không xác định. Trong ví dụ OPs, việc trình biên dịch chứng minh điều đó có vẻ tầm thường và do đó nó giống như thể toàn bộ chương trình là không xác định.

Chúng ta có thể thấy điều này từ Báo cáo Lỗi 109 mà điểm mấu chốt của nó yêu cầu:

Tuy nhiên, nếu Tiêu chuẩn C nhận ra sự tồn tại riêng biệt của "giá trị không xác định" (mà việc tạo đơn thuần không liên quan đến "hành vi không xác định" hoàn toàn) thì một người thực hiện thử nghiệm trình biên dịch có thể viết một trường hợp thử nghiệm như sau và anh ta / cô ta cũng có thể mong đợi (hoặc có thể yêu cầu) rằng một triển khai tuân thủ, ít nhất phải biên dịch mã này (và có thể cũng cho phép nó thực thi) mà không "thất bại".

int array1[5];
int array2[5];
int *p1 = &array1[0];
int *p2 = &array2[0];

int foo()
{
int i;
i = (p1 > p2); /* Must this be "successfully translated"? */
1/0; /* Must this be "successfully translated"? */
return 0;
}

Vì vậy, câu hỏi mấu chốt là: Đoạn mã trên phải được "dịch thành công" (bất kể điều đó có nghĩa là gì)? (Xem chú thích kèm theo điều khoản phụ 5.1.1.3.)

và câu trả lời là:

Tiêu chuẩn C sử dụng thuật ngữ "giá trị không xác định" chứ không phải "giá trị không xác định". Việc sử dụng một đối tượng có giá trị không xác định dẫn đến hành vi không xác định. Chú thích của điều khoản phụ 5.1.1.3 chỉ ra rằng việc triển khai có thể tự do tạo ra bất kỳ số lượng chẩn đoán nào miễn là chương trình hợp lệ vẫn được dịch chính xác. Nếu một biểu thức mà việc loại bỏ sẽ dẫn đến hành vi không xác định xuất hiện trong ngữ cảnh yêu cầu biểu thức hằng, thì chương trình chứa không tuân thủ nghiêm ngặt. Hơn nữa, nếu mọi thực thi có thể có của một chương trình nhất định sẽ dẫn đến hành vi không xác định, thì chương trình đã cho không tuân thủ nghiêm ngặt. Việc triển khai tuân thủ không được không dịch một chương trình tuân thủ nghiêm ngặt đơn giản vì một số khả năng thực thi chương trình đó sẽ dẫn đến hành vi không xác định. Bởi vì foo có thể không bao giờ được gọi, ví dụ được đưa ra phải được dịch thành công bằng một triển khai tuân thủ.

Trong C ++, cách tiếp cận có vẻ thoải mái hơn và sẽ đề xuất một chương trình có hành vi không xác định bất kể việc triển khai có thể chứng minh nó tĩnh hay không.

Chúng tôi có [intro.abstrac] p5 cho biết:

Một triển khai tuân thủ thực hiện một chương trình được định dạng tốt sẽ tạo ra cùng một hành vi có thể quan sát được như một trong những thực thi có thể có của phiên bản tương ứng của máy trừu tượng với cùng một chương trình và cùng một đầu vào. Tuy nhiên, nếu bất kỳ thực thi nào như vậy chứa một hoạt động không xác định, thì tài liệu này không yêu cầu việc triển khai thực hiện chương trình đó với đầu vào đó (thậm chí không liên quan đến các hoạt động trước hoạt động không xác định đầu tiên).

Câu trả lời hàng đầu là một quan niệm sai lầm (nhưng phổ biến):

Hành vi không xác định là thuộc tính thời gian chạy *. Nó KHÔNG THỂ "thời gian du lịch"!

Một số hoạt động nhất định được xác định (theo tiêu chuẩn) để có tác dụng phụ và không thể tối ưu hóa được. Các thao tác thực hiện I / O hoặc volatilecác biến truy cập thuộc loại này.

Tuy nhiên , có một lưu ý: UB có thể là bất kỳ hành vi nào , bao gồm cả hành vi hoàn tác các hoạt động trước đó. Điều này có thể gây ra hậu quả tương tự, trong một số trường hợp, đối với việc tối ưu hóa mã trước đó.

Trên thực tế, điều này phù hợp với câu trích dẫn trong câu trả lời trên cùng (phần nhấn mạnh của tôi):

Một triển khai tuân thủ thực hiện một chương trình được định dạng tốt sẽ tạo ra cùng một hành vi có thể quan sát được như một trong những thực thi có thể có của phiên bản tương ứng của máy trừu tượng có cùng chương trình và cùng một đầu vào.
Tuy nhiên, nếu bất kỳ quá trình thực hiện nào như vậy chứa một thao tác không xác định, thì tiêu chuẩn này không yêu cầu việc triển khai thực hiện chương trình đó với đầu vào đó (thậm chí không liên quan đến các thao tác trước thao tác không xác định đầu tiên).

Có, trích dẫn này nói "không liên quan đến các hoạt động trước hoạt động không xác định đầu tiên" , nhưng lưu ý rằng đây là đặc biệt về mã đang được thực thi , không chỉ được biên dịch.
Rốt cuộc, hành vi không xác định không thực sự được tiếp cận sẽ không làm gì cả và để dòng chứa UB thực sự được tiếp cận, mã đứng trước nó phải thực thi trước!

Vì vậy, có, một khi UB được thực thi , bất kỳ tác động nào của các hoạt động trước đó sẽ trở thành không xác định. Nhưng cho đến khi điều đó xảy ra, việc thực thi chương trình đã được xác định rõ.

Tuy nhiên, lưu ý rằng tất cả các lần thực thi chương trình dẫn đến việc này xảy ra có thể được tối ưu hóa cho các chương trình tương đương , bao gồm bất kỳ chương trình nào thực hiện các hoạt động trước đó nhưng sau đó bỏ tác dụng của chúng. Do đó, mã trước đó có thể được tối ưu hóa bất cứ khi nào làm như vậy sẽ tương đương với việc các hiệu ứng của chúng được hoàn tác ; nếu không, nó không thể. Xem ví dụ bên dưới.

* Lưu ý: Điều này không mâu thuẫn với UB xảy ra tại thời điểm biên dịch . Nếu trình biên dịch thực sự có thể chứng minh rằng mã UB sẽ luôn được thực thi cho tất cả các đầu vào, thì UB có thể kéo dài thời gian biên dịch. Tuy nhiên, điều này đòi hỏi phải biết rằng tất cả các mã trước đó cuối cùng sẽ trả về , đây là một yêu cầu mạnh mẽ. Một lần nữa, hãy xem ví dụ / giải thích bên dưới.

Để làm cho điều này cụ thể, hãy lưu ý rằng mã sau phải in foovà chờ đầu vào của bạn bất kể hành vi không xác định nào theo sau nó:

printf("foo");
getchar();
*(char*)1 = 1;

Tuy nhiên, cũng lưu ý rằng không có gì đảm bảo foosẽ vẫn còn trên màn hình sau khi UB xảy ra, hoặc ký tự bạn đã nhập sẽ không còn trong bộ đệm nhập nữa; cả hai thao tác này đều có thể được "hoàn tác", có tác dụng tương tự như "du hành thời gian" UB.

Nếu getchar()dòng không có ở đó, sẽ hợp pháp nếu các dòng được tối ưu hóa nếu và chỉ khi điều đó không thể phân biệt được với việc xuất ra foovà sau đó "hủy bỏ" nó.

Việc có thể phân biệt được hay không sẽ phụ thuộc hoàn toàn vào việc triển khai (tức là vào trình biên dịch và thư viện chuẩn của bạn). Ví dụ, bạn có thể printf chặn luồng của bạn ở đây trong khi chờ chương trình khác đọc đầu ra không? Hay nó sẽ trở lại ngay lập tức?

• Nếu nó có thể chặn ở đây, thì một chương trình khác có thể từ chối đọc đầu ra đầy đủ của nó, và nó có thể không bao giờ quay trở lại, và do đó UB có thể không bao giờ thực sự xảy ra.

• Nếu nó có thể trở lại ngay lập tức ở đây, thì chúng ta biết nó phải trở lại, và do đó tối ưu hóa nó hoàn toàn không thể phân biệt được với việc thực thi nó và sau đó bỏ tác dụng của nó.

Tất nhiên, vì trình biên dịch biết hành vi nào được phép đối với phiên bản cụ thể của printfnó, nó có thể tối ưu hóa tương ứng và do đó printfcó thể được tối ưu hóa trong một số trường hợp chứ không phải những trường hợp khác. Nhưng, một lần nữa, lời biện minh là điều này sẽ không thể phân biệt được với UB chưa thực hiện các hoạt động trước đó, chứ không phải mã trước đó bị "đầu độc" vì UB.