Cạm bẫy thiết kế API trong C [đã đóng]

Một số lỗ hổng khiến bạn thất vọng trong API C (bao gồm thư viện tiêu chuẩn, thư viện bên thứ ba và tiêu đề bên trong dự án) là gì? Mục tiêu là xác định các cạm bẫy thiết kế API trong C, vì vậy những người viết thư viện C mới có thể học hỏi từ những sai lầm trong quá khứ.

Giải thích tại sao lỗ hổng là xấu (tốt nhất là với một ví dụ) và cố gắng đề xuất một cải tiến. Mặc dù giải pháp của bạn có thể không thực tế trong cuộc sống thực (đã quá muộn để khắc phục strncpy), nhưng nó sẽ hỗ trợ cho các nhà văn thư viện trong tương lai.

Mặc dù trọng tâm của câu hỏi này là API C, các vấn đề ảnh hưởng đến khả năng sử dụng chúng trong các ngôn ngữ khác của bạn đều được chào đón.

Xin vui lòng cho một lỗ hổng cho mỗi câu trả lời, để dân chủ có thể sắp xếp các câu trả lời.

Các hàm với giá trị trả về không nhất quán hoặc không hợp lý. Hai ví dụ điển hình:

1) Một số chức năng của windows trả về TAY sử dụng NULL / 0 cho một lỗi (CreatThread), một số sử dụng INVALID_HANDLE_VALUE / -1 cho một lỗi (CreatFile).

2) Lỗi 'thời gian' của hàm POSIX '(time_t) -1', điều này thực sự phi logic vì 'time_t' có thể là loại đã ký hoặc không dấu.

Hàm hoặc tham số với tên không mô tả hoặc xác nhận gây nhầm lẫn. Ví dụ:

1) CreateFile, trong API Windows, không thực sự tạo một tệp, nó tạo ra một tệp xử lý. Nó có thể tạo một tệp, giống như 'mở' có thể, nếu được yêu cầu thông qua một tham số. Tham số này có các giá trị được gọi là 'CREATE_ALWAYS' và 'CREATE_NEW' có tên thậm chí không gợi ý về ngữ nghĩa của chúng. ('CREATE_ALWAYS' có nghĩa là nó không thành công nếu tập tin tồn tại? Hay nó tạo một tập tin mới ở trên nó? tập tin trên đầu trang của nó?)

2) pthread_cond_wait trong API pthreads POSIX, mặc dù tên của nó, là một sự chờ đợi vô điều kiện .

Các loại mờ đục được truyền qua giao diện dưới dạng loại xử lý đã xóa. Tất nhiên, vấn đề là trình biên dịch không thể kiểm tra mã người dùng để biết các loại đối số chính xác.

Điều này có nhiều hình thức và hương vị khác nhau, bao gồm, nhưng không giới hạn ở:

• void* lạm dụng

• sử dụng intnhư một trình xử lý tài nguyên (ví dụ: thư viện CDI)

• đối số được gõ

Các loại khác biệt hơn (= không thể được sử dụng thay thế hoàn toàn cho nhau) được ánh xạ tới cùng loại đã xóa, càng tệ. Tất nhiên, biện pháp khắc phục chỉ đơn giản là cung cấp các con trỏ mờ đục an toàn dọc theo dòng (ví dụ C):

typedef struct Foo Foo;
typedef struct Bar Bar;

Foo* createFoo();
Bar* createBar();

int doSomething(Foo* foo);
void somethingElse(Foo* foo, Bar* bar);

void destroyFoo(Foo* foo);
void destroyBar(Bar* bar);

Các hàm với các quy ước trả về chuỗi không nhất quán và thường rườm rà.

Ví dụ, getcwd yêu cầu bộ đệm do người dùng cung cấp và kích thước của nó. Điều này có nghĩa là một ứng dụng phải đặt giới hạn tùy ý về độ dài thư mục hiện tại hoặc thực hiện một cái gì đó như thế này ( từ CCAN ):

 /* *This* is why people hate C. */
len = 32;
cwd = talloc_array(ctx, char, len);
while (!getcwd(cwd, len)) {
    if (errno != ERANGE) {
        talloc_free(cwd);
        return NULL;
    }
    cwd = talloc_realloc(ctx, cwd, char, len *= 2);
}

Giải pháp của tôi: trả về một mallocchuỗi ed. Nó đơn giản, mạnh mẽ và không kém phần hiệu quả. Ngoại trừ các nền tảng nhúng và các hệ thống cũ hơn, mallocthực sự khá nhanh.

Các hàm lấy / trả về các kiểu dữ liệu hỗn hợp theo giá trị hoặc sử dụng các hàm gọi lại.

Thậm chí tệ hơn nếu loại nói là một liên minh hoặc chứa các trường bit.

Từ quan điểm của một người gọi C, những điều này thực sự ổn, nhưng tôi không viết bằng C hoặc C ++ trừ khi được yêu cầu, vì vậy tôi thường gọi qua FFI. Hầu hết các FFI không hỗ trợ các công đoàn hoặc trường bit và một số (như Haskell và MLton) không thể hỗ trợ các cấu trúc được truyền theo giá trị. Đối với những người có thể xử lý các cấu trúc theo giá trị, ít nhất Common Lisp và LuaJIT bị buộc vào các đường dẫn chậm - Giao diện chức năng đối ngoại chung của Lisp phải thực hiện cuộc gọi chậm qua libffi và LuaJIT từ chối biên dịch đường dẫn mã chứa cuộc gọi. Các hàm có thể gọi lại vào máy chủ cũng kích hoạt các đường dẫn chậm trên LuaJIT, Java và Haskell, với LuaJIT không thể biên dịch cuộc gọi như vậy.