In con trỏ rỗng với% p là hành vi không xác định?

Có phải hành vi không xác định để in con trỏ rỗng với mã %pđịnh nghĩa chuyển đổi không?

#include <stdio.h>

int main(void) {
    void *p = NULL;

    printf("%p", p);

    return 0;
}

Câu hỏi áp dụng cho tiêu chuẩn C chứ không áp dụng cho việc triển khai C.

Đây là một trong những trường hợp kỳ lạ khi chúng tôi phải tuân theo những hạn chế của ngôn ngữ tiếng Anh và cấu trúc không nhất quán trong tiêu chuẩn. Vì vậy, tốt nhất, tôi có thể đưa ra một lập luận phản bác thuyết phục, vì không thể chứng minh được điều đó :) ¹

Mã trong câu hỏi thể hiện hành vi được xác định rõ ràng.

Vì [7.1.4] là cơ sở của câu hỏi, hãy bắt đầu ở đó:

Mỗi phòng trong số báo cáo sau đây áp dụng trừ khi quy định rõ ràng trong các mô tả chi tiết tiếp theo: Nếu một đối số cho một hàm có giá trị không hợp lệ ( chẳng hạn như một giá trị bên ngoài lĩnh vực chức năng, hoặc một con trỏ ra ngoài không gian địa chỉ của chương trình, hoặc một con trỏ null , [... ví dụ khác ...] ) [...] hành vi là không xác định. [... các câu khác ...]

Đây là ngôn ngữ vụng về. Một cách hiểu là các mục trong danh sách là UB cho tất cả các chức năng của thư viện, trừ khi bị ghi đè bởi các mô tả riêng lẻ. Nhưng danh sách bắt đầu bằng "chẳng hạn như", cho thấy rằng nó mang tính minh họa, không đầy đủ. Ví dụ, nó không đề cập đến kết thúc null đúng của chuỗi (quan trọng đối với hành vi của ví dụ strcpy).

Vì vậy, rõ ràng mục đích / phạm vi của 7.1.4 chỉ đơn giản là "giá trị không hợp lệ" dẫn đến UB ( trừ khi có quy định khác ). Chúng ta phải xem xét mô tả của từng hàm để xác định những gì được coi là "giá trị không hợp lệ".

Ví dụ 1 - strcpy

[7.21.2.3] chỉ nói điều này:

Các strcpybản sao chức năng chuỗi trỏ đến bởi s2(bao gồm các ký tự null chấm dứt) vào mảng trỏ đến bởi s1. Nếu việc sao chép diễn ra giữa các đối tượng chồng lên nhau, hành vi đó là không xác định.

Nó không đề cập rõ ràng đến con trỏ null, nhưng nó cũng không đề cập đến dấu chấm dứt null. Thay vào đó, một suy luận từ "chuỗi được trỏ tới s2" rằng các giá trị hợp lệ duy nhất là chuỗi (tức là con trỏ đến mảng ký tự kết thúc bằng null).

Thật vậy, mô hình này có thể được nhìn thấy trong các mô tả riêng lẻ. Một số ví dụ khác:

• [7.6.4.1 (fenv)] lưu trữ các môi trường nổi-điểm hiện tại trong đối tượng được trỏ đến bởienvp

• [7.12.6.4 (frexp)] lưu trữ các số nguyên trong int tượng được trỏ đến bởiexp

• [7.19.5.1 (fclose)] các dòng chỉ vào bởistream

Ví dụ 2 - printf

[7.19.6.1] nói điều này về %p:

p- Đối số sẽ là một con trỏ tới void. Giá trị của con trỏ được chuyển đổi thành một chuỗi các ký tự in, theo cách thức được triển khai xác định.

Null là một giá trị con trỏ hợp lệ và phần này không đề cập rõ ràng rằng null là một trường hợp đặc biệt, cũng không phải con trỏ phải trỏ vào một đối tượng. Vì vậy, nó được xác định hành vi.

_{1. Trừ khi một tác giả tiêu chuẩn đưa ra, hoặc trừ khi chúng tôi có thể tìm thấy điều gì đó tương tự như một tài liệu cơ sở làm rõ mọi thứ.}

Câu trả lời ngắn gọn

Vâng . Việc in con trỏ rỗng với mã %pđịnh nghĩa chuyển đổi có hành vi không xác định. Phải nói rằng, tôi không biết về bất kỳ triển khai tuân thủ nào hiện có sẽ hoạt động sai.

Câu trả lời áp dụng cho bất kỳ tiêu chuẩn C nào (C89 / C99 / C11).

Câu trả lời dài

Bộ %pđịnh nghĩa chuyển đổi mong đợi một đối số của con trỏ kiểu vô hiệu, việc chuyển đổi con trỏ thành các ký tự có thể in được do việc triển khai xác định. Nó không nói rằng con trỏ null được mong đợi.

Phần giới thiệu về các hàm thư viện chuẩn nêu rõ rằng các con trỏ null làm đối số cho các hàm (thư viện chuẩn) được coi là các giá trị không hợp lệ, trừ khi nó được quy định rõ ràng khác.

C99 / C11 §7.1.4 p1

[...] Nếu một đối số của một hàm có giá trị không hợp lệ (chẳng hạn như [...] con trỏ null, [...] thì hành vi là không xác định.

Ví dụ cho các hàm (thư viện chuẩn) yêu cầu con trỏ null làm đối số hợp lệ:

• fflush() sử dụng con trỏ null để xả "tất cả các luồng" (áp dụng).
• freopen() sử dụng con trỏ null để chỉ ra tệp "hiện được liên kết" với luồng.
• snprintf() cho phép chuyển một con trỏ null khi 'n' bằng không.
• realloc() sử dụng một con trỏ null để cấp phát một đối tượng mới.
• free() cho phép chuyển một con trỏ null.
• strtok() sử dụng một con trỏ null cho các cuộc gọi tiếp theo.

Nếu chúng ta xét trường hợp cho snprintf(), sẽ hợp lý khi cho phép truyền một con trỏ null khi 'n' bằng 0, nhưng điều này không đúng với các hàm (thư viện chuẩn) khác cho phép một 'n' bằng 0 tương tự. Ví dụ: memcpy(), memmove(), strncpy(), memset(), memcmp().

Nó không chỉ được chỉ định trong phần giới thiệu về thư viện chuẩn mà còn một lần nữa trong phần giới thiệu về các chức năng này:

C99 §7.21.1 p2 / C11 §7.24.1 p2

Trong đó một đối số được khai báo là size_tn chỉ định độ dài của mảng cho một hàm, n có thể có giá trị bằng không khi gọi hàm đó. Trừ khi được nêu rõ ràng khác trong phần mô tả của một hàm cụ thể trong điều khoản phụ này, các đối số con trỏ trên một lệnh gọi như vậy sẽ vẫn có giá trị hợp lệ như được mô tả trong 7.1.4.

Có cố ý không?

Tôi không biết UB của %pvới một con trỏ null trên thực tế có cố ý hay không, nhưng vì tiêu chuẩn tuyên bố rõ ràng rằng con trỏ null được coi là giá trị không hợp lệ như là đối số của các hàm thư viện tiêu chuẩn và sau đó nó đi và chỉ định rõ ràng các trường hợp mà một null con trỏ là một đối số hợp lệ (snprintf, miễn phí, vv), và sau đó nó đi và một lần nữa lặp lại yêu cầu cho các đối số có giá trị ngay cả trong không trường hợp 'n' ( memcpy, memmove, memset), sau đó tôi nghĩ rằng nó là hợp lý để giả định rằng Ủy ban tiêu chuẩn C không quá quan tâm đến việc có những thứ như vậy không được xác định.

Các tác giả của Tiêu chuẩn C đã không cố gắng liệt kê đầy đủ tất cả các yêu cầu về hành vi mà việc triển khai phải đáp ứng để phù hợp với bất kỳ mục đích cụ thể nào. Thay vào đó, họ kỳ vọng rằng những người viết trình biên dịch sẽ thực hiện một số nhận thức chung nhất định cho dù Tiêu chuẩn có yêu cầu hay không.

Câu hỏi liệu một thứ gì đó gọi ra UB hiếm khi tự nó hữu ích. Các câu hỏi thực sự có tầm quan trọng là:

1. Ai đó đang cố gắng viết một trình biên dịch chất lượng có nên làm cho nó hoạt động theo kiểu có thể đoán trước được không? Đối với kịch bản được mô tả, câu trả lời rõ ràng là có.

2. Các lập trình viên có nên được quyền mong đợi rằng các trình biên dịch chất lượng cho bất kỳ thứ gì giống với các nền tảng bình thường sẽ hoạt động theo kiểu có thể đoán trước được không? Trong kịch bản được mô tả, tôi sẽ nói câu trả lời là có.

3. Có thể một số người viết trình biên dịch ngu ngốc kéo dài cách giải thích của Tiêu chuẩn để biện minh cho việc làm điều gì đó kỳ lạ? Tôi hy vọng là không, nhưng sẽ không loại trừ nó.

4. Trình biên dịch sanitizing có nên thắc mắc về hành vi này không? Điều đó sẽ phụ thuộc vào mức độ hoang tưởng của người dùng của họ; một trình biên dịch làm sạch có lẽ không nên mặc định là phản ứng dữ dội về hành vi như vậy, nhưng có lẽ cung cấp một tùy chọn cấu hình để thực hiện trong trường hợp các chương trình có thể được chuyển sang trình biên dịch "thông minh" / ngu ngốc hoạt động kỳ lạ.

Nếu một cách giải thích hợp lý của Tiêu chuẩn sẽ ngụ ý một hành vi được xác định, nhưng một số người viết trình biên dịch kéo dài cách giải thích để biện minh cho việc làm khác, thì liệu Tiêu chuẩn nói có thực sự quan trọng không?