Fragen? Antworten! Siehe auch: Alternativlos
Beginnen wir mit dem guten Teil: bsearch und qsort. Das API ist wohldefiniert, funktioniert verläßlich, und taugt auch im täglichen Leben. Gut, es gibt da noch vereinzelt Details, über die man sich lustig machen kann, z.B. daß qsort in der glibc nicht etwa ein Quicksort ist, sondern ein Mergesort :-) Aber hey, darüber kann man hinweg sehen.
Die anderen Kracher sind alle in <search.h>. Es gibt da z.B. so Gemmen wie lsearch und lfind. Beide kriegen wie bsearch eine Vergleichs-Funktion als Function Pointer übergeben und suchen linear in einem Array. Ja, linear. In der Zeit, in der ich eine Vergleichs-Funktion implementiert habe, habe ich das auch schnell inline hingeschrieben. Und lesbarer ist das auch. Wieso gibt es da zwei Funktionen? Weil eine von ihnen im Falle des Nicht-Findens das gesuchte Element am Ende anhängt. Wer sich jetzt denkt, daß die Funktion dann da schon realloc machen wird, täuscht sich. "Wird schon passen". What could possibly go wrong? Oh, welche sucht und welche fügt auch an? Ist anhand der Namen ja schwer zu sagen, gell? Ich zitiere mal die Linux-Manpage: BUGS: The naming is unfortunate.
Aber das ist bestimmt nur ein Ausreißer, mhh? Der Rest der Datei ist bestimmt brauchbar. Na mal gucken… insque und remque überzeugen auch auf Anhieb. Es gibt da zwei VAX-Instruktionen gleichen Namens, die Elemente in eine doppelt verkettete Liste einfügen. Und so erwarten insque und remque Zeiger auf eine struct, die einen next und einen previous Pointer am Anfang haben. Leider kann man das in C nicht ausdrücken, und so kriegen die Funktionen void* übergeben! Type-Check? Brauchen wir nicht. Und es gibt auch kein Konzept einer leeren Liste, und remque kann einem auch nicht mitteilen, wenn die Liste jetzt leer ist. Kurz: voll für den Fuß.
Aber wartet, es kommt noch mehr: hsearch sucht in einer Hash-Tabelle. Ja, einer. Das ist kein Argument an die Funktion, es gibt nur eine, implizite, statisch deklarierte, auf die man auch nicht direkt zugreifen kann. Warum auch, man hat ja hsearch. Und wenn man mehr als eine Hash-Tabelle braucht? Geht nicht. (Es gibt eine GNU Extension, mit der das dann doch geht)
Nun fragt man sich: wer kann so auf Drogen gewesen sein, sich so beschissene APIs auszudenken? Das können doch eigentlich nur die BSD-Junkies gewesen sein? Nein! Das ist System V! Das ist das Stinke-Unix, dessen übelriechenden Kadaver SCO gekauft hat. Es gibt in der Datei auch noch APIs für Suchbäume. Ich habe sie mir noch nicht angesehen, aber es würde mich wundern, wenn die was taugen.