C dilinde API tasarım tuzakları [kapalı]

C API'larında sizi çıldırtan bazı kusurlar nelerdir (standart kütüphaneler, üçüncü taraf kütüphaneleri ve bir projenin içindeki başlıklar dahil)? Amaç, C'deki API tasarım tuzaklarını tanımlamaktır, böylece yeni C kütüphaneleri yazan insanlar geçmişin hatalarından öğrenebilirler.

Kusurun neden kötü olduğunu (tercihen bir örnekle) açıklayın ve bir iyileştirme önermeye çalışın. Çözümünüz gerçek hayatta pratik olmasa da (düzeltmek için çok geç strncpy), gelecekteki kütüphane yazarları için kafa yormalıdır.

Bu sorunun odağı C API'ları olmasına rağmen, bunları diğer dillerde kullanma yeteneğinizi etkileyen sorunlar memnuniyetle karşılanmaktadır.

Lütfen cevap başına bir kusur verin, böylece demokrasi cevapları sıralayabilir.

Tutarsız veya mantıksız dönüş değerlerine sahip fonksiyonlar. İki iyi örnek:

1) HANDLE döndüren bazı windows işlevleri bir hata için NULL / 0 kullanır (CreateThread), bir hata için INVALID_HANDLE_VALUE / -1 kullanır (CreateFile).

2) 'time_t' imzalı veya imzasız bir tip olabileceğinden POSIX 'time' fonksiyonu hata durumunda '(time_t) -1' değerini döndürür.

Açıklayıcı olmayan veya olumlu bir şekilde kafa karıştırıcı isimlere sahip işlevler veya parametreler. Örneğin:

1) CreateFile, Windows API'sinde aslında bir dosya oluşturmaz, bir dosya tanıtıcısı oluşturur. Bir parametre aracılığıyla istenirse, tıpkı 'açık' gibi bir dosya oluşturabilir. Bu parametre, adları anlamlarında ipucu bile olmayan 'CREATE_ALWAYS' ve 'CREATE_NEW' adlı değerlere sahiptir. ('CREATE_ALWAYS' dosya varsa başarısız olduğu anlamına mı geliyor yoksa üstte yeni bir dosya mı oluşturuyor? 'CREATE_NEW' her zaman yeni bir dosya oluşturduğu ve dosya zaten mevcutsa başarısız olduğu anlamına mı geliyor? üstüne dosya?)

2) adına rağmen koşulsuz bir bekleme olan POSIX pthreads API'sındaki pthread_cond_wait .

Silinen tanıtıcılar olarak arabirimden geçirilen opak türler. Sorun, elbette, derleyicinin kullanıcı kodunu doğru argüman türleri için kontrol edememesidir.

Bu, aşağıdakiler dahil ancak bunlarla sınırlı olmamak üzere çeşitli formlarda ve tatlarda gelir:

• void* taciz

• kullanarak intbir kaynak kolu olarak (örnek: CDI kütüphanesi)

• dize olarak yazılan bağımsız değişkenler

Ne kadar farklı türler (= birbirinin yerine kullanılamazsa) aynı tür silinmiş türle eşleştirilirse, daha kötüdür. Tabii ki, çare basitçe (C örneği) çizgileri boyunca tipafe opak işaretçiler sağlamaktır:

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);

Tutarsız ve genellikle hantal dize döndürme kurallarına sahip işlevler.

Örneğin, getcwd kullanıcı tarafından sağlanan bir arabellek ve boyutunu ister. Bu, bir uygulamanın geçerli dizin uzunluğu üzerinde rasgele bir sınır ayarlaması veya bunun gibi bir şey yapması gerektiği anlamına gelir ( CCAN'dan ):

 /* *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);
}

Benim çözümüm: malloced dizesini döndür. Basit, sağlam ve daha az verimli değil. Gömülü platformlar ve eski sistemler dışında mallocaslında oldukça hızlı.

Bileşik veri türlerini değere göre alan / döndüren veya geri çağrı kullanan işlevler.

Adı geçen tür bir birleşim veya bit alanları içeriyorsa daha da kötüsü.

Bir C arayan açısından, bunlar aslında Tamam, ama gerekmedikçe C veya C ++ yazmıyorum, bu yüzden genellikle bir FFI aracılığıyla arıyorum. Çoğu FFI sendikaları veya bit alanlarını desteklemez ve bazıları (Haskell ve MLton gibi) değere göre aktarılan yapıları destekleyemez. By-value yapılarını işleyenler için, en azından Common Lisp ve LuaJIT yavaş yollara zorlanır - Lisp'in Ortak Yabancı İşlev Arayüzü libffi aracılığıyla yavaş bir çağrı yapmalıdır ve LuaJIT, JIT-çağrıyı içeren kod yolunu derlemeyi reddeder. Ana bilgisayarlara geri çağrılabilen işlevler, LuaJIT, Java ve Haskell'de yavaş yolları tetikler; LuaJIT böyle bir çağrıyı derleyemez.