ข้อผิดพลาดในการออกแบบ API ใน C [ปิด]

มีข้อบกพร่องอะไรบ้างที่ผลักดันคุณให้คลั่งไคล้ใน C APIs (รวมถึงห้องสมุดมาตรฐานห้องสมุดบุคคลที่สามและส่วนหัวภายในโครงการ) เป้าหมายคือการระบุข้อผิดพลาดในการออกแบบ API ใน C ดังนั้นผู้ที่เขียนไลบรารี C ใหม่สามารถเรียนรู้จากความผิดพลาดในอดีต

อธิบายว่าเหตุใดข้อบกพร่องจึงไม่ดี (ควรเป็นตัวอย่าง) และพยายามเสนอการปรับปรุง แม้ว่าวิธีการแก้ปัญหาของคุณอาจไม่สามารถใช้งานได้จริงในชีวิตจริง (มันสายเกินไปที่จะแก้ไขstrncpy) แต่ก็ควรให้ความสำคัญกับนักเขียนห้องสมุดในอนาคต

แม้ว่าจุดเน้นของคำถามนี้คือ C APIs แต่ปัญหาที่ส่งผลต่อความสามารถในการใช้ภาษาเหล่านี้ในภาษาอื่นก็สามารถทำได้

โปรดให้หนึ่งข้อบกพร่องต่อคำตอบเพื่อประชาธิปไตยสามารถเรียงลำดับคำตอบ

ฟังก์ชั่นที่มีค่าส่งคืนที่ไม่สอดคล้องกันหรือไร้เหตุผล สองตัวอย่างที่ดี:

1) ฟังก์ชัน windows บางอย่างที่ส่งกลับค่า HANDLE ให้ใช้ NULL / 0 สำหรับข้อผิดพลาด (CreateThread) บางฟังก์ชันใช้ INVALID_HANDLE_VALUE / -1 สำหรับข้อผิดพลาด (CreateFile)

2) ฟังก์ชัน POSIX 'time' ส่งคืน '(time_t) -1' โดยมีข้อผิดพลาดซึ่งไม่มีเหตุผลจริงๆเนื่องจาก 'time_t' อาจเป็นประเภทที่ลงชื่อหรือไม่ได้ลงนาม

ฟังก์ชั่นหรือพารามิเตอร์ที่มีชื่อที่ไม่อธิบายหรือทำให้เกิดความสับสน ตัวอย่างเช่น:

1) CreateFile ใน Windows API ไม่ได้สร้างไฟล์จริงๆมันสร้างตัวจัดการไฟล์ มันสามารถสร้างไฟล์เช่นเดียวกับ 'เปิด' ถ้าถามถึงผ่านพารามิเตอร์ พารามิเตอร์นี้มีค่าที่เรียกว่า 'CREATE_ALWAYS' และ 'CREATE_NEW' โดยที่ชื่อนั้นไม่ได้บอกใบ้ถึงความหมายของมัน ('CREATE_ALWAYS' หมายความว่าไฟล์ล้มเหลวหรือไม่หรือสร้างไฟล์ใหม่ที่ด้านบนของไฟล์หรือไม่ 'CREATE_NEW' หมายความว่าสร้างไฟล์ใหม่เสมอและล้มเหลวหากไฟล์มีอยู่แล้วหรือไม่หรือสร้างใหม่ ไฟล์ด้านบนของมัน?)

2) pthread_cond_wait ใน POSIX pthreads API ซึ่งแม้ชื่อจะเป็นการรออย่างไม่มีเงื่อนไข

ชนิดทึบแสงที่ส่งผ่านอินเทอร์เฟซเป็นการจัดการชนิดที่ถูกลบ แน่นอนว่าปัญหาคือคอมไพเลอร์ไม่สามารถตรวจสอบรหัสผู้ใช้เพื่อหาประเภทอาร์กิวเมนต์ที่ถูกต้อง

สิ่งนี้มาในรูปแบบและรสชาติที่หลากหลายรวมถึง แต่ไม่ จำกัด เพียง:

• void* การละเมิด

• ใช้intเป็นตัวจัดการทรัพยากร (ตัวอย่าง: ไลบรารี CDI)

• อาร์กิวเมนต์ที่พิมพ์อย่างสตริง

ประเภทที่แตกต่างกันมากขึ้น (= ไม่สามารถใช้แทนกันได้อย่างสมบูรณ์) ถูกแมปกับประเภทที่ถูกลบประเภทเดียวกันที่เลวร้ายยิ่ง แน่นอนการรักษาคือการให้ตัวชี้ทึบแสง typesafe ตามบรรทัดของ (ตัวอย่าง 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 FFIs ส่วนใหญ่ไม่สนับสนุนสหภาพหรือบิตฟิลด์และบางส่วน (เช่น Haskell และ MLton) ไม่สามารถรองรับ structs ที่ส่งผ่านตามค่า สำหรับสิ่งที่สามารถจัดการกับค่าโครงสร้างอย่างน้อย Common Lisp และ LuaJIT ถูกบังคับให้เข้าสู่เส้นทางที่ช้า - Common Foreign Interface Interface ของ Lisp ต้องทำการเรียกช้าผ่าน libffi และ LuaJIT ปฏิเสธที่จะรวบรวมเส้นทางของรหัสที่มีการโทร ฟังก์ชั่นที่อาจโทรกลับไปยังโฮสต์ยังทำให้เกิดเส้นทางที่ช้าใน LuaJIT, Java และ Haskell ด้วย LuaJIT ที่ไม่สามารถรวบรวมการโทรดังกล่าวได้