C의 API 디자인 함정

C API (표준 라이브러리, 타사 라이브러리 및 프로젝트 내부의 헤더 포함)에서 문제를 일으키는 몇 가지 결함은 무엇입니까? 목표는 C에서 API 디자인의 함정을 식별하여 새로운 C 라이브러리를 작성하는 사람들이 과거의 실수로부터 배울 수 있도록하는 것입니다.

결함이 왜 나쁜지 설명하고 (예를 들어서 바람직 함) 개선을 제안하려고합니다. 귀하의 솔루션이 실제 환경에서는 실용적이지 않을 수도 있지만 (해결하기에는 너무 늦습니다 strncpy), 미래의 도서관 작가에게 머리를 기울여야합니다.

이 질문의 초점은 C API이지만 다른 언어로 사용하는 데 영향을주는 문제는 환영합니다.

답변 당 하나의 결함을 제시하여 민주주의가 답변을 정렬 할 수 있습니다.

일치하지 않거나 비논리적 인 반환 값이있는 함수 두 가지 좋은 예 :

1) HANDLE을 반환하는 일부 Windows 함수는 오류 (CreateThread)에 NULL / 0을 사용하고 일부는 오류 (CreateFile)에 INVALID_HANDLE_VALUE / -1을 사용합니다.

2) POSIX 'time'함수는 오류시 '(time_t) -1'을 반환합니다. 'time_t'는 부호있는 유형이거나 부호없는 유형일 수 있으므로 실제로는 비논리적입니다.

비 설명 적이거나 혼동되는 이름을 가진 기능 또는 매개 변수. 예를 들면 다음과 같습니다.

1) Windows API에서 CreateFile은 실제로 파일을 만들지 않고 파일 핸들을 만듭니다. 매개 변수를 통해 요청하면 '열기'와 마찬가지로 파일을 만들 수 있습니다. 이 매개 변수에는 이름이 의미를 암시하지 않는 '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)는 값으로 전달 된 구조체를 지원할 수 없습니다. 값별 구조체를 처리 할 수있는 사용자의 경우 최소한 공통 Lisp 및 LuaJIT가 느린 경로로 강제 실행됩니다. Lisp의 Common Foreign Function Interface는 libffi를 통해 느린 호출을 수행해야하며 LuaJIT는 호출이 포함 된 코드 경로를 JIT 컴파일하지 않습니다. 호스트로 다시 호출 할 수있는 함수도 LuaJIT, Java 및 Haskell에서 느린 경로를 트리거하며 LuaJIT는 이러한 호출을 컴파일 할 수 없습니다.