สาขาที่มีพฤติกรรมที่ไม่ได้กำหนดสามารถถือว่าไม่สามารถเข้าถึงได้และปรับให้เหมาะสมเป็นรหัสตายได้หรือไม่

พิจารณาข้อความต่อไปนี้:

*((char*)NULL) = 0; //undefined behavior

มันก่อให้เกิดพฤติกรรมที่ไม่ได้กำหนดไว้อย่างชัดเจน การมีอยู่ของคำสั่งดังกล่าวในโปรแกรมที่กำหนดหมายความว่าโปรแกรมทั้งหมดไม่ได้กำหนดไว้หรือพฤติกรรมนั้นจะไม่ได้กำหนดก็ต่อเมื่อโฟลว์การควบคุมมาถึงคำสั่งนี้

โปรแกรมต่อไปนี้จะถูกกำหนดไว้อย่างดีในกรณีที่ผู้ใช้ไม่เคยป้อนหมายเลข3หรือไม่?

while (true) {
 int num = ReadNumberFromConsole();
 if (num == 3)
  *((char*)NULL) = 0; //undefined behavior
}

หรือเป็นพฤติกรรมที่ไม่ได้กำหนดโดยสิ้นเชิงไม่ว่าผู้ใช้จะเข้ามา?

นอกจากนี้คอมไพเลอร์สามารถสันนิษฐานได้ว่าพฤติกรรมที่ไม่ได้กำหนดจะไม่ถูกดำเนินการในรันไทม์? ซึ่งจะช่วยให้สามารถใช้เหตุผลย้อนหลังได้:

int num = ReadNumberFromConsole();

if (num == 3) {
 PrintToConsole(num);
 *((char*)NULL) = 0; //undefined behavior
}

ที่นี่คอมไพเลอร์อาจให้เหตุผลว่าในกรณีที่num == 3เรามักจะเรียกใช้พฤติกรรมที่ไม่ได้กำหนด ดังนั้นกรณีนี้จะต้องเป็นไปไม่ได้และไม่จำเป็นต้องพิมพ์หมายเลข ifคำสั่งทั้งหมดสามารถปรับให้เหมาะสมได้ การให้เหตุผลย้อนหลังแบบนี้ได้รับอนุญาตตามมาตรฐานหรือไม่?

การมีอยู่ของคำสั่งดังกล่าวในโปรแกรมที่กำหนดหมายความว่าโปรแกรมทั้งหมดไม่ได้กำหนดไว้หรือพฤติกรรมนั้นจะไม่ได้กำหนดก็ต่อเมื่อโฟลว์การควบคุมเข้าสู่คำสั่งนี้?

ทั้งสองอย่าง เงื่อนไขแรกแข็งแรงเกินไปและข้อที่สองอ่อนแอเกินไป

บางครั้งการเข้าถึงวัตถุจะเรียงตามลำดับ แต่มาตรฐานจะอธิบายพฤติกรรมของโปรแกรมนอกเวลา Danvil ยกมาแล้ว:

หากการดำเนินการใด ๆ ดังกล่าวมีการดำเนินการที่ไม่ได้กำหนดมาตรฐานสากลฉบับนี้ไม่ได้กำหนดข้อกำหนดเกี่ยวกับการดำเนินการตามโปรแกรมนั้นด้วยข้อมูลเข้านั้น (ไม่เกี่ยวกับการดำเนินการก่อนการดำเนินการที่ไม่ได้กำหนดไว้เป็นครั้งแรก)

สิ่งนี้สามารถตีความได้:

หากการดำเนินการของโปรแกรมทำให้เกิดพฤติกรรมที่ไม่ได้กำหนดแสดงว่าทั้งโปรแกรมมีพฤติกรรมที่ไม่ได้กำหนดไว้

ดังนั้นคำสั่งที่ไม่สามารถเข้าถึงได้กับ UB จึงไม่ทำให้โปรแกรม UB คำสั่งที่เข้าถึงได้ว่า (เนื่องจากค่าของอินพุต) ไม่ถึงไม่ให้โปรแกรม UB นั่นเป็นเหตุผลที่เงื่อนไขแรกของคุณแข็งแรงเกินไป

ตอนนี้คอมไพเลอร์ไม่สามารถบอกได้ว่า UB มีอะไรบ้าง ดังนั้นเพื่อให้เครื่องมือเพิ่มประสิทธิภาพสามารถเรียงลำดับคำสั่งใหม่ด้วย UB ที่เป็นไปได้ซึ่งจะสั่งซื้อใหม่ได้หากมีการกำหนดพฤติกรรมของพวกเขาจำเป็นต้องอนุญาตให้ UB "ย้อนเวลากลับไป" และผิดพลาดก่อนที่จะถึงจุดลำดับก่อนหน้า (หรือใน C ++ 11 คำศัพท์เพื่อให้ UB มีผลต่อสิ่งต่าง ๆ ที่เรียงตามลำดับก่อนหน้าสิ่ง UB) ดังนั้นเงื่อนไขที่สองของคุณอ่อนแอเกินไป

ตัวอย่างที่สำคัญคือเมื่อเครื่องมือเพิ่มประสิทธิภาพใช้นามแฝงที่เข้มงวด จุดรวมของกฎการกำหนดนามแฝงที่เข้มงวดคือการอนุญาตให้คอมไพเลอร์สั่งการดำเนินการใหม่ที่ไม่สามารถเรียงลำดับใหม่ได้อย่างถูกต้องหากเป็นไปได้ว่าพอยน์เตอร์ที่เป็นปัญหาแทนหน่วยความจำเดียวกัน ดังนั้นหากคุณใช้ตัวชี้นามแฝงอย่างผิดกฎหมายและ UB เกิดขึ้นก็อาจส่งผลต่อคำสั่ง "before" ของคำสั่ง UB ได้อย่างง่ายดาย เท่าที่เครื่องจักรนามธรรมเกี่ยวข้องคำสั่ง UB ยังไม่ถูกดำเนินการ เท่าที่เกี่ยวข้องกับรหัสออบเจ็กต์จริงรหัสนั้นได้ถูกดำเนินการบางส่วนหรือทั้งหมดแล้ว แต่มาตรฐานไม่ได้พยายามที่จะลงรายละเอียดเกี่ยวกับความหมายของเครื่องมือเพิ่มประสิทธิภาพในการจัดลำดับคำสั่งใหม่หรือผลกระทบของสิ่งนั้นสำหรับ UB เพียงแค่ให้ใบอนุญาตการใช้งานผิดพลาดทันทีที่พอใจ

คุณสามารถคิดว่านี่คือ "UB มีไทม์แมชชีน"

เพื่อตอบตัวอย่างของคุณโดยเฉพาะ:

• พฤติกรรมจะไม่ได้กำหนดก็ต่อเมื่ออ่าน 3
• คอมไพเลอร์สามารถและกำจัดโค้ดได้อย่างตายตัวหากบล็อกพื้นฐานมีการดำเนินการบางอย่างที่ไม่ได้กำหนดไว้ พวกเขาได้รับอนุญาต (และฉันคาดเดาว่าจะทำ) ในกรณีที่ไม่ใช่บล็อกพื้นฐาน แต่ทุกสาขานำไปสู่ ​​UB ตัวอย่างนี้ไม่ใช่ตัวเลือกเว้นแต่PrintToConsole(3)จะทราบแน่ชัดว่าจะกลับมา มันอาจทำให้เกิดข้อยกเว้นหรืออะไรก็ได้

ตัวอย่างที่คล้ายกับที่สองของคุณคือตัวเลือก gcc -fdelete-null-pointer-checksซึ่งสามารถใช้รหัสเช่นนี้ได้ (ฉันยังไม่ได้ตรวจสอบตัวอย่างนี้โดยพิจารณาว่าเป็นตัวอย่างของแนวคิดทั่วไป):

void foo(int *p) {
    if (p) *p = 3;
    std::cout << *p << '\n';
}

และเปลี่ยนเป็น:

*p = 3;
std::cout << "3\n";

ทำไม? เพราะถ้าpเป็นโมฆะโค้ดก็มี UB อยู่ดีดังนั้นคอมไพเลอร์อาจถือว่าไม่เป็นโมฆะและปรับให้เหมาะสม เคอร์เนลลินุกซ์สะดุดเหนือสิ่งนี้ ( https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1897 ) เป็นหลักเนื่องจากทำงานในโหมดที่ไม่ควรอ้างถึงตัวชี้ค่าว่างเป็น UB คาดว่าจะส่งผลให้เกิดข้อยกเว้นฮาร์ดแวร์ที่กำหนดไว้ซึ่งเคอร์เนลสามารถจัดการได้ เมื่อเปิดใช้งานการเพิ่มประสิทธิภาพ gcc จำเป็นต้องใช้-fno-delete-null-pointer-checksเพื่อให้การรับประกันที่เกินมาตรฐานนั้น

ป.ล. คำตอบที่ใช้ได้จริงสำหรับคำถาม "พฤติกรรมที่ไม่ได้กำหนดจะเกิดขึ้นเมื่อใด" คือ "10 นาทีก่อนที่คุณจะออกเดินทางในวันนั้น"

มาตรฐานระบุไว้ที่ 1.9 / 4

[หมายเหตุ: มาตรฐานสากลฉบับนี้ไม่ได้กำหนดข้อกำหนดเกี่ยวกับพฤติกรรมของโปรแกรมที่มีพฤติกรรมที่ไม่ได้กำหนดไว้ - หมายเหตุ]

ประเด็นที่น่าสนใจน่าจะเป็นความหมาย "ประกอบด้วย" หลังจากนั้นเล็กน้อยที่ 1.9 / 5 จะระบุ:

อย่างไรก็ตามหากการดำเนินการใด ๆ ดังกล่าวมีการดำเนินการที่ไม่ได้กำหนดมาตรฐานสากลฉบับนี้ไม่ได้กำหนดข้อกำหนดใด ๆ เกี่ยวกับการดำเนินการตามโปรแกรมนั้นด้วยอินพุตนั้น (ไม่ได้เกี่ยวข้องกับการดำเนินการก่อนการดำเนินการที่ไม่ได้กำหนดไว้เป็นครั้งแรก)

ในที่นี้กล่าวถึง "การดำเนินการ ... ด้วยข้อมูลนั้น" โดยเฉพาะ ฉันจะตีความว่าพฤติกรรมที่ไม่ได้กำหนดไว้ในสาขาหนึ่งที่เป็นไปได้ซึ่งไม่ได้ดำเนินการในตอนนี้จะไม่มีผลต่อสาขาการดำเนินการปัจจุบัน

อย่างไรก็ตามปัญหาที่แตกต่างกันคือสมมติฐานที่ขึ้นอยู่กับพฤติกรรมที่ไม่ได้กำหนดไว้ในระหว่างการสร้างโค้ด ดูคำตอบของ Steve Jessop สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้

ตัวอย่างคำแนะนำคือ

int foo(int x)
{
    int a;
    if (x)
        return a;
    return 0;
}

ทั้ง GCC ปัจจุบันและ Clang ปัจจุบันจะปรับให้เหมาะสม (บน x86) เป็น

xorl %eax,%eax
ret

เนื่องจากอนุมานว่าxเป็นศูนย์เสมอจาก UB ในif (x)เส้นทางควบคุม GCC จะไม่แจ้งเตือนการใช้ค่าที่ไม่ได้เริ่มต้นด้วยซ้ำ! (เนื่องจากบัตรผ่านที่ใช้ตรรกะข้างต้นทำงานก่อนบัตรผ่านที่สร้างคำเตือนค่าที่ไม่ได้เริ่มต้น)

ร่างการทำงาน C ++ ปัจจุบันกล่าวใน 1.9.4 ว่า

มาตรฐานสากลฉบับนี้ไม่ได้กำหนดข้อกำหนดเกี่ยวกับพฤติกรรมของโปรแกรมที่มีพฤติกรรมที่ไม่ถูกต้อง

จากสิ่งนี้ฉันจะบอกว่าโปรแกรมที่มีพฤติกรรมที่ไม่ได้กำหนดบนเส้นทางการดำเนินการใด ๆ สามารถทำอะไรก็ได้ทุกครั้งที่ดำเนินการ

มีบทความที่ดีจริงๆสองเรื่องเกี่ยวกับพฤติกรรมที่ไม่ได้กำหนดและสิ่งที่คอมไพเลอร์มักจะทำ:

• คำแนะนำเกี่ยวกับพฤติกรรมที่ไม่ได้กำหนดใน C และ C ++
• สิ่งที่โปรแกรมเมอร์ C ทุกคนควรรู้เกี่ยวกับพฤติกรรมที่ไม่ได้กำหนด

คำว่าพฤติกรรมหมายถึงสิ่งที่กำลังทำทำStatemenr ที่ไม่ถูกประหารไม่ใช่ "พฤติกรรม"

ภาพประกอบ:

*ptr = 0;

เป็นพฤติกรรมที่ไม่ได้กำหนดหรือไม่? สมมติว่าเรามั่นใจ 100%ptr == nullptrน้อยหนึ่งครั้งในระหว่างการเรียกใช้โปรแกรม คำตอบควรเป็นใช่

อะไรประมาณนี้

 if (ptr) *ptr = 0;

ไม่ได้กำหนดไว้หรือไม่? (จำptr == nullptrอย่างน้อยหนึ่งครั้งได้หรือไม่) ฉันหวังว่าจะไม่เป็นอย่างนั้นคุณจะไม่สามารถเขียนโปรแกรมที่มีประโยชน์ได้เลย

ไม่ได้รับอันตรายใด ๆ ในการทำคำตอบนี้

พฤติกรรมที่ไม่ได้กำหนดจะเกิดขึ้นเมื่อโปรแกรมจะทำให้เกิดพฤติกรรมที่ไม่ได้กำหนดไม่ว่าจะเกิดอะไรขึ้นต่อไป อย่างไรก็ตามคุณให้ตัวอย่างต่อไปนี้

int num = ReadNumberFromConsole();

if (num == 3) {
 PrintToConsole(num);
 *((char*)NULL) = 0; //undefined behavior
}

เว้นแต่คอมไพลเลอร์จะทราบคำจำกัดความของPrintToConsoleก็ไม่สามารถลบif (num == 3)เงื่อนไขได้ สมมติว่าคุณมีส่วนหัวของระบบที่มีการประกาศดังต่อไปนี้LongAndCamelCaseStdio.hPrintToConsole

void PrintToConsole(int);

ไม่มีอะไรเป็นประโยชน์เลยใช่ไหม ตอนนี้เรามาดูกันว่าความชั่วร้าย (หรืออาจจะไม่ชั่วถึงขนาดพฤติกรรมที่ไม่ได้กำหนดอาจแย่ลง) ผู้ขายคืออะไรโดยการตรวจสอบคำจำกัดความที่แท้จริงของฟังก์ชันนี้

int printf(const char *, ...);
void exit(int);

void PrintToConsole(int num) {
    printf("%d\n", num);
    exit(0);
}

จริงๆแล้วคอมไพเลอร์ต้องสมมติว่าฟังก์ชันใด ๆ โดยพลการที่คอมไพเลอร์ไม่รู้ว่ามันทำอะไรอยู่อาจออกหรือทำให้เกิดข้อยกเว้น (ในกรณีของ C ++) คุณสามารถสังเกตได้ว่า*((char*)NULL) = 0;จะไม่ถูกดำเนินการเนื่องจากการดำเนินการจะไม่ดำเนินต่อไปหลังจากนั้นPrintToConsoleโทร

พฤติกรรมที่ไม่ได้กำหนดจะเกิดขึ้นเมื่อใด PrintToConsoleส่งคืนจริง คอมไพเลอร์คาดว่าสิ่งนี้จะไม่เกิดขึ้น (เนื่องจากจะทำให้โปรแกรมดำเนินการตามพฤติกรรมที่ไม่ได้กำหนดไม่ว่าจะเกิดอะไรขึ้นก็ตาม) ดังนั้นอะไรก็เกิดขึ้นได้

อย่างไรก็ตามลองพิจารณาอย่างอื่น สมมติว่าเรากำลังทำการตรวจสอบค่าว่างและใช้ตัวแปรหลังจากการตรวจสอบค่าว่าง

int putchar(int);

const char *warning;

void lol_null_check(const char *pointer) {
    if (!pointer) {
        warning = "pointer is null";
    }
    putchar(*pointer);
}

ในกรณีนี้สังเกตได้ง่ายว่าlol_null_checkต้องใช้ตัวชี้ที่ไม่ใช่ NULL การกำหนดให้กับwarningตัวแปรGlobal non-volatile ไม่ใช่สิ่งที่สามารถออกจากโปรแกรมหรือทำให้เกิดข้อยกเว้นใด ๆ pointerนี้ยังไม่ระเหยจึงไม่สามารถได้อย่างน่าอัศจรรย์เปลี่ยนค่าในช่วงกลางของฟังก์ชั่น (ถ้ามันไม่เป็นพฤติกรรมที่ไม่ได้กำหนด) การโทรlol_null_check(NULL)จะทำให้เกิดพฤติกรรมที่ไม่ได้กำหนดซึ่งอาจทำให้ไม่สามารถกำหนดตัวแปรได้ (เนื่องจาก ณ จุดนี้จะทราบข้อเท็จจริงที่ว่าโปรแกรมเรียกใช้พฤติกรรมที่ไม่ได้กำหนดไว้)

อย่างไรก็ตามพฤติกรรมที่ไม่ได้กำหนดหมายความว่าโปรแกรมสามารถทำอะไรก็ได้ ดังนั้นจึงไม่มีสิ่งใดหยุดพฤติกรรมที่ไม่ได้กำหนดไว้ไม่ให้ย้อนเวลากลับไปและทำให้โปรแกรมของคุณหยุดทำงานก่อนที่จะint main()ดำเนินการบรรทัดแรก เป็นพฤติกรรมที่ไม่ได้กำหนดไม่จำเป็นต้องมีเหตุผล มันอาจผิดพลาดหลังจากพิมพ์ 3 แต่พฤติกรรมที่ไม่ได้กำหนดจะย้อนเวลากลับไปและหยุดทำงานก่อนที่คุณจะพิมพ์ 3 และใครจะรู้ว่าพฤติกรรมที่ไม่ได้กำหนดอาจเขียนทับ RAM ระบบของคุณและทำให้ระบบของคุณพังใน 2 สัปดาห์ต่อมา ในขณะที่โปรแกรมที่ไม่ได้กำหนดของคุณไม่ทำงาน

หากโปรแกรมถึงคำสั่งที่เรียกใช้พฤติกรรมที่ไม่ได้กำหนดจะไม่มีข้อกำหนดใด ๆ วางอยู่บนผลลัพธ์ / พฤติกรรมใด ๆ ของโปรแกรมใด ๆ ไม่สำคัญว่าพฤติกรรมที่ไม่ได้กำหนดจะเกิดขึ้น "ก่อน" หรือ "หลัง"

เหตุผลของคุณเกี่ยวกับข้อมูลโค้ดทั้งสามถูกต้อง โดยเฉพาะอย่างยิ่งคอมไพลเลอร์อาจปฏิบัติต่อคำสั่งใด ๆ ที่เรียกใช้พฤติกรรมที่ไม่ได้กำหนดโดยไม่มีเงื่อนไขตามที่ GCC ปฏิบัติ__builtin_unreachable(): เนื่องจากคำใบ้ในการปรับให้เหมาะสมที่สุดว่าคำสั่งนั้นไม่สามารถเข้าถึงได้ (และด้วยเหตุนี้เส้นทางรหัสทั้งหมดที่นำไปสู่รหัสนั้นจะไม่สามารถเข้าถึงได้โดยไม่มีเงื่อนไข) การเพิ่มประสิทธิภาพอื่น ๆ ที่คล้ายกันนั้นเป็นไปได้แน่นอน

มาตรฐานจำนวนมากสำหรับสิ่งต่างๆหลายประเภทใช้ความพยายามอย่างมากในการอธิบายสิ่งต่างๆที่การนำไปใช้งานไม่ควรทำหรือไม่ควรทำโดยใช้ระบบการตั้งชื่อที่คล้ายกับที่กำหนดไว้ในIETF RFC 2119 (แม้ว่าจะไม่จำเป็นต้องอ้างถึงคำจำกัดความในเอกสารนั้นก็ตาม) ในหลาย ๆ กรณีคำอธิบายของสิ่งที่การนำไปใช้งานควรทำยกเว้นในกรณีที่สิ่งเหล่านั้นจะไร้ประโยชน์หรือไม่สามารถใช้งานได้จริงมีความสำคัญมากกว่าข้อกำหนดที่การใช้งานที่สอดคล้องกันทั้งหมดจะต้องเป็นไปตาม

น่าเสียดายที่มาตรฐาน C และ C ++ มีแนวโน้มที่จะละเว้นคำอธิบายของสิ่งต่าง ๆ ซึ่งแม้ว่าจะไม่จำเป็นต้องใช้ 100% แต่ก็ควรได้รับการคาดหวังจากการใช้งานที่มีคุณภาพซึ่งไม่ได้บันทึกพฤติกรรมที่ขัดกัน ข้อเสนอแนะที่ว่าการใช้งานควรทำบางสิ่งบางอย่างอาจถูกมองว่าเป็นนัยว่าสิ่งที่ไม่ด้อยกว่าและในกรณีที่โดยทั่วไปแล้วจะเห็นได้ชัดว่าพฤติกรรมใดจะเป็นประโยชน์หรือปฏิบัติได้จริงเมื่อเทียบกับการนำไปใช้ไม่ได้และไม่มีประโยชน์ในการนำไปใช้งานนั้นจะมี ความต้องการเพียงเล็กน้อยที่มาตรฐานจะแทรกแซงการตัดสินดังกล่าว

คอมไพเลอร์ที่ชาญฉลาดสามารถปฏิบัติตามมาตรฐานได้ในขณะที่กำจัดโค้ดใด ๆ ที่จะไม่มีผลยกเว้นเมื่อโค้ดได้รับอินพุตที่จะทำให้เกิดพฤติกรรมที่ไม่ได้กำหนดอย่างหลีกเลี่ยงไม่ได้ แต่ "ฉลาด" และ "โง่" ไม่ใช่คำตรงข้าม ความจริงที่ว่าผู้เขียนมาตรฐานได้ตัดสินใจว่าอาจมีการนำไปใช้งานบางประเภทที่การประพฤติเป็นประโยชน์ในสถานการณ์ที่กำหนดจะไร้ประโยชน์และไม่เป็นประโยชน์ไม่ได้หมายความถึงการตัดสินใด ๆ ว่าพฤติกรรมดังกล่าวควรได้รับการพิจารณาว่าเป็นประโยชน์และเป็นประโยชน์ต่อผู้อื่น หากการนำไปใช้งานสามารถรักษาการรับประกันพฤติกรรมได้โดยไม่มีค่าใช้จ่ายใด ๆ นอกเหนือจากการสูญเสียโอกาสในการตัด "สาขาที่ตายแล้ว" รหัสผู้ใช้มูลค่าเกือบทั้งหมดจะได้รับจากการรับประกันนั้นจะเกินค่าใช้จ่ายในการจัดหา การกำจัดกิ่งตายอาจใช้ได้ดีในกรณีที่ไม่จำเป็นต้องยอมแพ้แต่ถ้าในรหัสผู้ใช้สถานการณ์ที่กำหนดได้มีการจัดการเกือบทุกพฤติกรรมที่เป็นไปได้อื่น ๆกว่าการกำจัดตายสาขารหัสผู้ใช้ความพยายามใด ๆ ที่จะต้องใช้จ่ายเพื่อหลีกเลี่ยงการ UB มีแนวโน้มที่จะเกินค่าที่ประสบความสำเร็จจาก DBE