Triết lý đằng sau hành vi không xác định

Thông số kỹ thuật của C \ C ++ bỏ qua một số lượng lớn các hành vi mở cho trình biên dịch thực hiện theo cách riêng của chúng. Có một số câu hỏi luôn luôn được hỏi ở đây về cùng và chúng tôi có một số bài viết tuyệt vời về nó:

• https://stackoverflow.com/questions/367633/what-are-all-the-common-undained-behaviour-that-ac-programmer-should-ledge-abo
• https://stackoverflow.com/questions/4105120/what-is-undDef-behavior
• https://stackoverflow.com/questions/4176328/undained-behavior-and- resultence-point

Câu hỏi của tôi không phải là về hành vi không xác định là gì, hoặc nó thực sự xấu. Tôi biết những nguy hiểm và hầu hết các trích dẫn hành vi không xác định có liên quan từ tiêu chuẩn, vì vậy xin vui lòng không đăng câu trả lời về mức độ xấu của nó. Câu hỏi này là về triết lý đằng sau để lại rất nhiều hành vi mở cho việc thực hiện trình biên dịch.

Tôi đọc một bài đăng blog tuyệt vời nói rằng hiệu suất là lý do chính. Tôi đã tự hỏi nếu hiệu suất là tiêu chí duy nhất để cho phép nó, hoặc có bất kỳ yếu tố nào khác ảnh hưởng đến quyết định để mọi thứ mở cho việc thực hiện trình biên dịch?

Nếu bạn có bất kỳ ví dụ nào để trích dẫn về cách một hành vi không xác định cụ thể cung cấp đủ chỗ cho trình biên dịch để tối ưu hóa, vui lòng liệt kê chúng. Nếu bạn biết bất kỳ yếu tố nào khác ngoài hiệu suất, vui lòng quay lại câu trả lời của bạn với đủ chi tiết.

Nếu bạn không hiểu câu hỏi hoặc không có đủ bằng chứng / nguồn để trả lời câu trả lời của bạn, xin vui lòng không đăng rộng rãi câu trả lời suy đoán.

Đầu tiên, tôi sẽ lưu ý rằng mặc dù tôi chỉ đề cập đến "C" ở đây, điều tương tự cũng thực sự áp dụng tương tự với C ++.

Nhận xét đề cập đến Godel là một phần (nhưng chỉ một phần) về điểm.

Khi bạn đi xuống, hành vi không xác định trong các tiêu chuẩn C phần lớn chỉ là chỉ ra ranh giới giữa những gì các tiêu chuẩn cố gắng xác định và những gì nó không.

Các định lý của Godel (có hai) về cơ bản nói rằng không thể định nghĩa một hệ thống toán học có thể được chứng minh (bằng các quy tắc riêng của nó) để hoàn chỉnh và nhất quán. Bạn có thể đưa ra các quy tắc của mình để có thể hoàn thành (trường hợp anh ấy xử lý là quy tắc "bình thường" cho các số tự nhiên) hoặc nếu không bạn có thể chứng minh tính nhất quán của nó, nhưng bạn không thể có cả hai.

Trong trường hợp của một cái gì đó như C, điều đó không áp dụng trực tiếp - đối với hầu hết các phần, "khả năng chứng minh" về tính hoàn chỉnh hoặc tính nhất quán của hệ thống không phải là ưu tiên cao đối với hầu hết các nhà thiết kế ngôn ngữ. Đồng thời, vâng, có lẽ họ đã bị ảnh hưởng (ít nhất là ở một mức độ nào đó) khi biết rằng không thể xác định một hệ thống "hoàn hảo" - một hệ thống hoàn toàn có thể chứng minh được. Biết rằng một điều như vậy là không thể có thể làm cho việc lùi lại, thở một chút và quyết định giới hạn của những gì họ sẽ cố gắng xác định sẽ dễ dàng hơn một chút.

Có nguy cơ (một lần nữa) bị buộc tội kiêu ngạo, tôi mô tả tiêu chuẩn C là bị chi phối (một phần) bởi hai ý tưởng cơ bản:

1. Ngôn ngữ nên hỗ trợ càng nhiều phần cứng càng tốt (lý tưởng nhất là tất cả phần cứng "lành mạnh" xuống giới hạn thấp hơn hợp lý).
2. Ngôn ngữ nên hỗ trợ viết càng nhiều phần mềm càng tốt cho môi trường nhất định.

Điều đầu tiên có nghĩa là nếu ai đó định nghĩa một CPU mới, thì có thể cung cấp một triển khai C tốt, chắc chắn, có thể sử dụng được cho điều đó, miễn là thiết kế rơi ít nhất là gần với một vài hướng dẫn đơn giản - về cơ bản, nếu nó tuân theo thứ gì đó theo thứ tự chung của mô hình Von Neumann và cung cấp ít nhất một lượng bộ nhớ tối thiểu hợp lý, đủ để cho phép thực hiện C. Để triển khai "được lưu trữ" (một chương trình chạy trên HĐH), bạn cần hỗ trợ một số khái niệm tương ứng chặt chẽ với các tệp và có một bộ ký tự với một bộ ký tự tối thiểu nhất định (yêu cầu 91).

Thứ hai có nghĩa là có thể viết mã thao tác trực tiếp với phần cứng, do đó bạn có thể viết những thứ như bộ tải khởi động, hệ điều hành, phần mềm nhúng chạy mà không cần bất kỳ HĐH nào, v.v ... Cuối cùng cũng có một số giới hạn hệ thống thực tiễn điều hành, bộ nạp khởi động, vv, là khả năng chứa ít nhất một chút chút mã viết bằng ngôn ngữ lắp ráp. Tương tự như vậy, ngay cả một hệ thống nhúng nhỏ cũng có khả năng bao gồm ít nhất một số loại thói quen thư viện được viết sẵn để cấp quyền truy cập vào các thiết bị trên hệ thống máy chủ. Mặc dù một ranh giới chính xác rất khó xác định, mục đích là sự phụ thuộc vào mã đó phải được giữ ở mức tối thiểu.

Hành vi không xác định trong ngôn ngữ chủ yếu được thúc đẩy bởi ý định cho ngôn ngữ hỗ trợ các khả năng này. Ví dụ: ngôn ngữ cho phép bạn chuyển đổi một số nguyên tùy ý thành một con trỏ và truy cập bất cứ điều gì xảy ra tại địa chỉ đó. Tiêu chuẩn không cố gắng nói điều gì sẽ xảy ra khi bạn làm (ví dụ, thậm chí đọc từ một số địa chỉ có thể có ảnh hưởng bên ngoài). Đồng thời, nó không cố gắng ngăn bạn làm những việc như vậy, bởi vì bạn cần phải có một số loại phần mềm mà bạn có thể viết bằng C.

Có một số hành vi không xác định được thúc đẩy bởi các yếu tố thiết kế khác là tốt. Ví dụ, một mục đích khác của C là hỗ trợ biên dịch riêng. Điều này có nghĩa (ví dụ) rằng nó có ý định rằng bạn có thể "liên kết" các mảnh lại với nhau bằng cách sử dụng một trình liên kết theo hầu hết những gì chúng ta xem là mô hình thông thường của trình liên kết. Cụ thể, có thể kết hợp các mô-đun được biên dịch riêng biệt thành một chương trình hoàn chỉnh mà không cần biết về ngữ nghĩa của ngôn ngữ.

Có một loại hành vi không xác định khác (phổ biến hơn nhiều trong C ++ so với C), hiện diện đơn giản là do các giới hạn về công nghệ trình biên dịch - những điều mà về cơ bản chúng ta biết là lỗi và có thể muốn trình biên dịch chẩn đoán là lỗi, nhưng với các giới hạn hiện tại về công nghệ trình biên dịch, điều đáng nghi ngờ là chúng có thể được chẩn đoán trong mọi trường hợp. Nhiều trong số này được điều khiển bởi các yêu cầu khác, chẳng hạn như để biên dịch riêng biệt, do đó, phần lớn là vấn đề cân bằng các yêu cầu xung đột, trong trường hợp ủy ban thường chọn hỗ trợ các khả năng lớn hơn, ngay cả khi điều đó có nghĩa là thiếu chẩn đoán một số vấn đề có thể xảy ra, thay vì giới hạn các khả năng để đảm bảo rằng tất cả các vấn đề có thể được chẩn đoán.

Những khác biệt về ý định này thúc đẩy hầu hết sự khác biệt giữa C và một cái gì đó như Java hoặc các hệ thống dựa trên CLI của Microsoft. Cái sau khá hạn chế để làm việc với một bộ phần cứng hạn chế hơn nhiều, hoặc yêu cầu phần mềm phải mô phỏng phần cứng cụ thể hơn mà chúng nhắm tới. Họ cũng đặc biệt có ý định ngăn chặn mọi thao tác trực tiếp đối với phần cứng, thay vào đó yêu cầu bạn sử dụng một cái gì đó như JNI hoặc P / Gọi (và mã được viết bằng thứ gì đó như C) để thực hiện một nỗ lực như vậy.

Quay trở lại các định lý của Godel một lúc, chúng ta có thể rút ra một điều song song: Java và CLI đã chọn phương án "nhất quán nội bộ", trong khi C đã chọn phương án "hoàn chỉnh". Tất nhiên, đây là một loại suy rất thô - Tôi nghi ngờ ai ấy cố gắng một bằng chứng chính thức hoặc là nhất quán nội bộ hoặc tính đầy đủ trong cả hai trường hợp. Tuy nhiên, khái niệm chung không phù hợp khá chặt chẽ với những lựa chọn mà họ đã thực hiện.

Các C lý do giải thích

Các thuật ngữ hành vi không xác định, hành vi không xác định và hành vi được xác định thực hiện được sử dụng để phân loại kết quả của việc viết chương trình có các thuộc tính mà Tiêu chuẩn không hoặc không thể mô tả hoàn toàn. Mục tiêu của việc áp dụng phân loại này là cho phép một số loại nhất định trong số các triển khai cho phép chất lượng thực hiện trở thành một lực lượng tích cực trên thị trường cũng như cho phép các tiện ích mở rộng phổ biến nhất định mà không cần loại bỏ bộ đệm tuân thủ Tiêu chuẩn. Phụ lục F của Danh mục tiêu chuẩn những hành vi thuộc một trong ba loại này.

Hành vi không xác định cung cấp cho người thực hiện một số vĩ độ trong việc dịch các chương trình. Vĩ độ này không kéo dài đến mức không dịch được chương trình.

Hành vi không xác định cung cấp cho giấy phép người thực hiện không bắt lỗi nhất định của chương trình khó chẩn đoán. Nó cũng xác định các khu vực có thể mở rộng ngôn ngữ phù hợp: người triển khai có thể tăng ngôn ngữ bằng cách cung cấp định nghĩa về hành vi không xác định chính thức.

Hành vi xác định thực hiện cho phép người thực hiện tự do lựa chọn cách tiếp cận phù hợp, nhưng yêu cầu lựa chọn này phải được giải thích cho người dùng. Các hành vi được chỉ định là định nghĩa triển khai thường là những hành vi mà người dùng có thể đưa ra quyết định mã hóa có ý nghĩa dựa trên định nghĩa triển khai. Các nhà triển khai nên ghi nhớ tiêu chí này khi quyết định mức độ mở rộng của một định nghĩa triển khai. Như với hành vi không xác định, chỉ đơn giản là không dịch nguồn có chứa hành vi được xác định thực hiện không phải là một phản ứng thích hợp.

Quan trọng cũng là lợi ích cho các chương trình, không chỉ là lợi ích cho việc thực hiện. Một chương trình phụ thuộc vào hành vi không xác định vẫn có thể tuân thủ , nếu nó được chấp nhận bởi việc thực hiện tuân thủ. Sự tồn tại của hành vi không xác định cho phép chương trình sử dụng các tính năng không di động được đánh dấu rõ ràng như vậy ("hành vi không xác định"), mà không trở nên không tuân thủ. Các ghi chú hợp lý:

Mã C có thể không di động. Mặc dù nó cố gắng tạo cơ hội cho các lập trình viên viết các chương trình di động thực sự, Ủy ban không muốn buộc các lập trình viên phải viết một cách hợp lý, để ngăn chặn việc sử dụng C như một 'trình biên dịch cấp cao' ': khả năng viết cụ thể của máy mã là một trong những điểm mạnh của C. Chính nguyên tắc này phần lớn thúc đẩy việc phân biệt giữa chương trình tuân thủ nghiêm ngặt và chương trình tuân thủ (§1.7).

Và tại 1.7 nó ghi chú

Định nghĩa ba lần về tuân thủ được sử dụng để mở rộng dân số của các chương trình tuân thủ và phân biệt giữa các chương trình tuân thủ bằng cách sử dụng một chương trình tuân thủ di động và thực hiện duy nhất.

Một chương trình tuân thủ nghiêm ngặt là một thuật ngữ khác cho một chương trình di động tối đa. Mục tiêu là cung cấp cho các lập trình viên một cơ hội chiến đấu để tạo ra các chương trình C mạnh mẽ cũng có tính di động cao, mà không làm giảm các chương trình C hoàn toàn hữu ích mà không thể mang theo được. Do đó trạng từ nghiêm chỉnh.

Do đó, chương trình bẩn nhỏ này hoạt động hoàn hảo trên GCC vẫn đang tuân thủ !

Điều tốc độ đặc biệt là một vấn đề khi so sánh với C. Nếu C ++ đã làm một số điều có thể hợp lý, như khởi tạo các mảng lớn của các kiểu nguyên thủy, nó sẽ mất một tấn điểm chuẩn cho mã C. Vì vậy, C ++ khởi tạo các kiểu dữ liệu của riêng nó, nhưng để lại các kiểu C theo cách chúng tồn tại.

Hành vi không xác định khác chỉ phản ánh thực tế. Một ví dụ là dịch chuyển bit với số lượng lớn hơn loại. Điều đó thực sự khác nhau giữa các thế hệ phần cứng của cùng một gia đình. Nếu bạn có ứng dụng 16 bit, cùng một nhị phân sẽ cho kết quả khác nhau trên 80286 và 80386. Vì vậy, tiêu chuẩn ngôn ngữ nói rằng chúng ta không biết!

Một số thứ chỉ được giữ nguyên như vậy, giống như thứ tự đánh giá các biểu hiện phụ không được chỉ định. Ban đầu điều này được cho là để giúp các nhà văn biên dịch tối ưu hóa tốt hơn. Ngày nay các trình biên dịch đủ tốt để tìm ra nó, nhưng chi phí tìm tất cả các vị trí trong các trình biên dịch hiện có tận dụng sự tự do là quá cao.

Như một ví dụ, truy cập con trỏ hầu như không được xác định và không nhất thiết chỉ vì lý do hiệu suất. Ví dụ, trên một số hệ thống, tải các thanh ghi cụ thể bằng một con trỏ sẽ tạo ra ngoại lệ phần cứng. Khi SPARC truy cập một đối tượng bộ nhớ được căn chỉnh không đúng sẽ gây ra lỗi bus, nhưng trên x86, nó sẽ "chậm". Thật khó để xác định hành vi trong những trường hợp đó vì phần cứng cơ bản chỉ ra điều gì sẽ xảy ra và C ++ có thể di chuyển được với rất nhiều loại phần cứng.

Tất nhiên nó cũng cho phép trình biên dịch tự do sử dụng kiến ​​thức cụ thể về kiến ​​trúc. Đối với một ví dụ hành vi không xác định, việc dịch chuyển đúng các giá trị đã ký có thể là logic hoặc số học tùy thuộc vào phần cứng cơ bản, để cho phép sử dụng bất kỳ thao tác dịch chuyển nào có sẵn và không bắt buộc mô phỏng phần mềm của nó.

Tôi cũng tin rằng nó làm cho công việc của trình biên dịch trở nên dễ dàng hơn nhưng tôi không thể nhớ lại ví dụ vừa rồi. Tôi sẽ thêm nó nếu tôi nhớ lại tình huống.

Đơn giản: Tốc độ và tính di động. Nếu C ++ đảm bảo rằng bạn có một ngoại lệ khi bạn hủy tham chiếu một con trỏ không hợp lệ, thì nó sẽ không thể chuyển sang phần cứng nhúng. Nếu C ++ đảm bảo một số thứ khác như luôn luôn khởi tạo nguyên thủy, thì nó sẽ chậm hơn và trong thời điểm xuất phát của C ++, chậm hơn là một điều thực sự, thực sự tồi tệ.

C đã được phát minh trên một máy có byte 9 bit và không có đơn vị dấu phẩy động - giả sử rằng nó đã bắt buộc các byte phải là 9 bit, từ 18 bit và phao có nên được thực hiện bằng cách sử dụng chuẩn IEEE754 không?

Tôi không nghĩ lý do đầu tiên của UB là để cho trình biên dịch tối ưu hóa, nhưng chỉ có khả năng sử dụng triển khai rõ ràng cho các mục tiêu tại thời điểm khi các kiến ​​trúc đã đa dạng hơn bây giờ (hãy nhớ nếu C được thiết kế trên một PDP-11 có kiến ​​trúc hơi quen thuộc, cổng đầu tiên là Honeywell 635 ít quen thuộc hơn - địa chỉ từ, sử dụng từ 36 bit, byte 6 hoặc 9 bit, địa chỉ 18 bit ... ít nhất là nó sử dụng 2 bổ sung). Nhưng nếu tối ưu hóa nặng không phải là mục tiêu, thì việc triển khai rõ ràng không bao gồm thêm kiểm tra thời gian chạy cho tràn, số lượng ca trên kích thước đăng ký, bí danh trong các biểu thức sửa đổi nhiều giá trị.

Một điều khác được tính đến là dễ thực hiện. Trình biên dịch AC tại thời điểm đó là nhiều lượt sử dụng nhiều tiến trình vì có một tiến trình xử lý mọi thứ sẽ không thể thực hiện được (chương trình sẽ quá lớn). Yêu cầu kiểm tra mạch lạc nặng đã được thực hiện - đặc biệt là khi nó liên quan đến một số CU. (Một chương trình khác ngoài trình biên dịch C, lint, đã được sử dụng cho điều đó).

Một trong những trường hợp cổ điển ban đầu đã được ký bổ sung số nguyên. Trên một số bộ xử lý đang sử dụng, điều đó sẽ gây ra lỗi và đối với các bộ xử lý khác, nó sẽ tiếp tục với một giá trị (có thể là giá trị mô-đun thích hợp). Chỉ định một trong hai trường hợp có nghĩa là các chương trình cho các máy có kiểu số học không thuận lợi sẽ phải có thêm mã, bao gồm một nhánh có điều kiện, cho một cái gì đó tương tự như phép cộng số nguyên.

Tôi muốn nói rằng nó ít về triết học hơn là về thực tế - C luôn là ngôn ngữ đa nền tảng và tiêu chuẩn phải phản ánh điều đó và thực tế là tại thời điểm bất kỳ tiêu chuẩn nào được đưa ra, sẽ có một số lượng lớn các triển khai trên rất nhiều phần cứng khác nhau. Một tiêu chuẩn cấm hành vi cần thiết sẽ bị coi thường hoặc tạo ra một cơ quan tiêu chuẩn cạnh tranh.

Một số hành vi không thể được xác định bởi bất kỳ phương tiện hợp lý. Tôi có nghĩa là truy cập một con trỏ bị xóa. Cách duy nhất để phát hiện nó sẽ là cấm giá trị con trỏ sau khi xóa (ghi nhớ giá trị của nó ở đâu đó và không cho phép bất kỳ hàm phân bổ nào trả về nó nữa). Không chỉ việc ghi nhớ như vậy sẽ là quá mức cần thiết, mà trong một chương trình chạy dài sẽ gây ra việc hết các giá trị con trỏ được phép.

Tôi sẽ cho bạn một ví dụ trong đó có khá nhiều sự lựa chọn hợp lý ngoài hành vi không xác định. Về nguyên tắc, bất kỳ con trỏ nào cũng có thể trỏ đến bộ nhớ chứa bất kỳ biến nào, ngoại trừ các biến cục bộ mà trình biên dịch có thể biết chưa bao giờ lấy địa chỉ của chúng. Tuy nhiên, để có được hiệu năng chấp nhận được trên CPU hiện đại, trình biên dịch phải sao chép các giá trị biến vào các thanh ghi. Hoạt động hoàn toàn ra khỏi bộ nhớ là không khởi động.

Điều này về cơ bản cung cấp cho bạn hai sự lựa chọn:

1) Xóa mọi thứ khỏi thanh ghi trước khi truy cập thông qua một con trỏ, chỉ trong trường hợp con trỏ trỏ đến bộ nhớ của biến đó. Sau đó tải mọi thứ cần thiết trở lại vào thanh ghi, chỉ trong trường hợp các giá trị được thay đổi thông qua con trỏ.

2) Có một bộ quy tắc khi con trỏ được phép đặt bí danh cho một biến và khi trình biên dịch được phép giả định rằng con trỏ không bí danh một biến.

C opts cho tùy chọn 2, bởi vì 1 sẽ là khủng khiếp cho hiệu suất. Nhưng sau đó, điều gì xảy ra nếu một con trỏ bí danh một biến theo cách mà quy tắc C cấm? Vì hiệu ứng phụ thuộc vào việc trình biên dịch có thực sự lưu trữ biến trong một thanh ghi hay không, không có cách nào để chuẩn C đảm bảo chắc chắn các kết quả cụ thể.

Trong lịch sử, Hành vi không xác định có hai mục đích chính:

1. Để tránh yêu cầu các tác giả biên dịch tạo mã để xử lý các điều kiện không bao giờ xảy ra.

2. Để cho phép khả năng trong trường hợp không có mã để xử lý rõ ràng các điều kiện như vậy, việc triển khai có thể có nhiều loại hành vi "tự nhiên", trong một số trường hợp, sẽ hữu ích.

Một ví dụ đơn giản, trên một số nền tảng phần cứng, cố gắng cộng hai số nguyên có dấu dương có tổng quá lớn để khớp với một số nguyên đã ký sẽ mang lại một số nguyên âm được ký cụ thể. Trên các triển khai khác, nó sẽ kích hoạt bẫy bộ xử lý. Để tiêu chuẩn C bắt buộc một trong hai hành vi sẽ yêu cầu trình biên dịch cho các nền tảng có hành vi tự nhiên khác với tiêu chuẩn sẽ phải tạo thêm mã để mang lại hành vi chính xác - mã có thể đắt hơn mã để thực hiện bổ sung thực tế. Tồi tệ hơn, điều đó có nghĩa là các lập trình viên muốn có hành vi "tự nhiên" sẽ phải thêm nhiều mã hơn nữa để đạt được nó (và mã bổ sung đó sẽ lại đắt hơn so với bổ sung).

Thật không may, một số tác giả biên dịch đã đưa ra triết lý rằng các trình biên dịch nên tìm cách tạo ra các điều kiện gợi lên Hành vi không xác định và, cho rằng các tình huống như vậy có thể không bao giờ xảy ra, rút ​​ra những suy luận mở rộng từ đó. Do đó, trên một hệ thống có 32 bit int, mã đã cho như:

uint32_t foo(uint16_t q, int *p)
{
  if (q > 46340)
    *p++;
  return q*q;
}

tiêu chuẩn C sẽ cho phép trình biên dịch nói rằng nếu q lớn hơn 46341 hoặc lớn hơn, biểu thức q * q sẽ mang lại kết quả quá lớn để phù hợp với int, do đó gây ra Hành vi không xác định và do đó, trình biên dịch sẽ có quyền cho rằng không thể xảy ra và do đó sẽ không được yêu cầu tăng *pnếu nó xảy ra. Nếu mã gọi sử dụng *pnhư một chỉ báo cần loại bỏ kết quả tính toán, thì hiệu quả của việc tối ưu hóa có thể là lấy mã mang lại kết quả hợp lý trên các hệ thống thực hiện theo hầu hết mọi cách có thể tưởng tượng được với tràn số nguyên (bẫy có thể là xấu, nhưng ít nhất sẽ hợp lý), và biến nó thành mã có thể hành xử vô nghĩa.

Hiệu quả là lý do thông thường, nhưng bất kể lý do gì, hành vi không xác định là một ý tưởng khủng khiếp cho tính di động. Trong thực tế, các hành vi không xác định trở thành không được xác minh, các giả định không có căn cứ.