Підводні камені API в C [закрито]

Які деякі недоліки викликають гайки в API API (включаючи стандартні бібліотеки, сторонні бібліотеки та заголовки всередині проекту)? Мета полягає у визначенні підводних каменів API в C, щоб люди, що пишуть нові бібліотеки С, могли вчитися на помилках минулого.

Поясніть, чому вада погана (бажано на прикладі), і спробуйте запропонувати поліпшення. Хоча ваше рішення може не бути практичним у реальному житті (це вже пізно виправити strncpy), воно повинно дати голову майбутнім бібліотечним письменникам.

Хоча це питання приділяється API API, проблеми, які впливають на вашу здатність використовувати їх іншими мовами, вітаються.

Будь ласка, дайте один недолік за кожну відповідь, щоб демократія могла сортувати відповіді.

Функції з непослідовними або нелогічними значеннями повернення. Два хороших приклади:

1) Деякі функції Windows, які повертають HANDLE, використовують помилку NULL / 0 (CreateThread), деякі використовують INVALID_HANDLE_VALUE / -1 для помилки (CreateFile).

2) Функція POSIX 'time' повертається '(time_t) -1' при помилці, що дійсно нелогічно, оскільки 'time_t' може бути або підписаним, або непідписаним типом.

Функції або параметри з не описовими або стверджувально заплутаними іменами. Наприклад:

1) CreateFile в API Windows фактично не створює файл, він створює обробку файлу. Він може створити файл так само, як "відкрити", якщо його попросять через параметр. Цей параметр має значення "CREATE_ALWAYS" та "CREATE_NEW", імена яких навіть не натякають на їх семантику. (Чи означає "CREATE_ALWAYS" невдачу, якщо файл існує? Або він створює новий файл поверх нього? Чи "CREATE_NEW" означає, що він створює новий файл завжди і виходить з ладу, якщо файл вже існує? Або він створює новий файл зверху?)

2) pthread_cond_wait в API pthreads POSIX, який, незважаючи на свою назву, - безумовне очікування.

Непрозорі типи, які передаються через інтерфейс у вигляді видалених ручок. Проблема, звичайно, полягає в тому, що компілятор не може перевірити код користувача на наявність правильних типів аргументів.

Це різноманітні форми та аромати, включаючи, але не обмежуючись ними:

• void* зловживання

• використання intв якості обробки ресурсів (приклад: бібліотека CDI)

• строго набрані аргументи

Чим чіткіші типи (= неможливо використовувати повністю взаємозамінно) відображаються на видалений тип однотипного типу, тим гірше. Звичайно, засіб полягає в тому, щоб просто надати непрозорі вказівники на основі типу C (наприклад, 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);

Функції з непослідовними і часто громіздкими умовами повернення рядків.

Наприклад, getcwd запитує буфер, що надається користувачем, та його розмір. Це означає, що програма або повинна встановити довільну межу поточної довжини каталогу, або зробити щось подібне ( від 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);
}

Моє рішення: повернути mallocрядок ed. Це просто, надійно і не менш ефективно. За винятком вбудованих платформ та старих систем, mallocнасправді досить швидко.

Функції, які приймають / повертають складові типи даних за значенням або використовують зворотні виклики.

Ще гірше, якщо згаданий тип є об'єднанням або містить бітові поля.

З точки зору того, хто телефонує на C, це насправді нормально, але я не пишу на C або C ++, якщо цього не потрібно, тому я зазвичай телефоную через FFI. Більшість FFI не підтримують об'єднання або бітові поля, а деякі (наприклад, Haskell і MLton) не можуть підтримувати структури, передані за значенням. Для тих, хто може управляти структурами за значенням, принаймні загальні Lisp та LuaJIT змушені проходити повільними шляхами - загальний зовнішній функціональний інтерфейс Lisp повинен здійснювати повільний дзвінок через libffi, і LuaJIT відмовляється JIT-компілювати шлях коду, що містить виклик. Функції, які можуть передзвонити в хости, також запускають повільні шляхи на LuaJIT, Java та Haskell, при цьому LuaJIT не може зібрати такий виклик.