CでのAPI設計の落とし穴[終了]

C API（標準ライブラリ、サードパーティのライブラリ、プロジェクト内のヘッダーなど）の問題を引き起こす欠陥は何ですか？目標は、CでのAPI設計の落とし穴を特定することです。これにより、新しいCライブラリを作成するユーザーは、過去の過ちから学ぶことができます。

欠陥が悪い理由を説明し（できれば例を挙げて）、改善策を提案してください。あなたの解決策は実際には実用的ではないかもしれませんが（修正するには遅すぎますstrncpy）、将来のライブラリライターのために準備を整える必要があります。

この質問の焦点はC APIですが、他の言語でそれらを使用する能力に影響を与える問題は大歓迎です。

民主主義が回答を分類できるように、回答ごとに1つの欠陥を指定してください。

一貫性のない、または非論理的な戻り値を持つ関数。2つの良い例：

1）HANDLEを返す一部のWindows関数は、エラー（CreateThread）にNULL / 0を使用し、エラー（CreateFile）にINVALID_HANDLE_VALUE / -1を使用するものがあります。

2）POSIXの 'time'関数はエラー時に '（time_t）-1'を返します。これは、 'time_t'が符号付きまたは符号なしの型になる可能性があるため、実際には非論理的です。

説明的ではない、または明確に混乱する名前の関数またはパラメーター。例えば：

1）Windows APIのCreateFileは実際にはファイルを作成せず、ファイルハンドルを作成します。パラメータを介して要求された場合、 'open'と同様にファイルを作成できます。このパラメーターには「CREATE_ALWAYS」および「CREATE_NEW」と呼ばれる値があり、これらの名前はセマンティクスを示すものすらありません。（「CREATE_ALWAYS」は、ファイルが存在する場合に失敗することを意味しますか？それともその上に新しいファイルを作成しますか？「CREATE_NEW」は常に新しいファイルを作成し、ファイルがすでに存在する場合は失敗することを意味しますか？それとも新しいファイルを作成しますか？その上にファイル？）

2）POSIX pthreads APIのpthread_cond_waitは、その名前にもかかわらず、無条件の待機です。

タイプ削除ハンドルとしてインターフェースを介して渡される不透明タイプ。もちろん問題は、コンパイラがユーザーコードをチェックして正しい引数の型を確認できないことです。

これには、次のようなさまざまな形式とフレーバーがあります。

• void* 乱用

• intリソースハンドルとして使用（例：CDIライブラリ）

• 文字列型引数

より明確なタイプ（=完全に互換的に使用することはできません）は、同じタイプの削除されたタイプにマップされます。もちろん、救済策は単純に（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);
}

私の解決策：malloced文字列を返します。シンプルで堅牢、そして効率も同じです。組み込みプラットフォームと古いシステムを除いて、malloc実際にはかなり高速です。

値によって複合データ型を取得/返す関数、またはコールバックを使用する関数。

上記の型が共用体であるか、ビットフィールドを含んでいる場合はさらに悪いことです。

Cの呼び出し側から見ると、これらは実際には問題ありませんが、必要でない限り、CまたはC ++で記述しないため、通常はFFI経由で呼び出します。ほとんどのFFIは、共用体またはビットフィールドをサポートしていません。また、一部（HaskellやMLtonなど）は、値で渡される構造体をサポートできません。値による構造体を処理できるものについては、少なくともCommon LispとLuaJITが遅いパスに強制されます-LispのCommon Foreign Function Interfaceはlibffi経由で遅い呼び出しを行う必要があり、LuaJITは呼び出しを含むコードパスのJITコンパイルを拒否します。ホストにコールバックする可能性のある関数は、LuaJIT、Java、およびHaskellで低速パスをトリガーし、LuaJITはそのような呼び出しをコンパイルできません。