> Вы видели первую версию API ldap_search(), без _ext* ? Вот это называется
> "логично и корректно", а то что я привел - уже писали
> долбаные наркоманы, попытавшиеся запихнуть множество из того, что раньше настраивалось
> через десяток вызовов ldap_set_option() opaque-хэндла в параметры одного вызова поиска.
> Вся сокетная подсистема на этом стиле живёт, весь ioctl, netlink, и много
> кто ещё (sqlite, mysql, ...). И только авторы openldap-а Дартаньяны, и
> знают как надо библиотечное api проектировать для Си.
> А то что там в коде можно найти ещё более лютый ппц
> - я ни минуты не сомневаюсь.

ldap_search() просто вызывает ldap_search_ex() подставляя кучу NULL.

Использовать отдельные функции для установки каких-то unusual опций или параметров не всегда удобно.
Точнее говоря, это требует создание, поддержки и удаления некоторого контекста.
Тогда ldap_search() превратиться минимум в три вызова: ldap_search_request_create(), ldap_search_request_execute(), ldap_search_request_destroy(). Плюс еще десяток функций на установку всяческих опций и контроллов.

В результате функция с несколькими параметрами превратиться в десяток-два функций и прочих конструкций. Притом что "на самом деле" ldap_search() формирует и выполняет один запрос, и примерно никакие лишние/дополнительные стейты ему не нужны.

Сравнение с API уровня ioctl() и т.д. совершенно не корректно. Во-первых, тут важнее совместимость, т.е. к уже существующему простейшему API добавляют какие-то опции. Во-вторых, в этих API уже есть естественно существующий и необходимый контекст/стейт. В-третьих, тем не менее, такое управление опциями через несколько ioctl() создает огромный оверхед на системных вызовах, с которым как-то пытаются бороться (например в glibc).

С другой стороны, ldap_search_ex() легко оборачивается в кружева на С++. Которые позволяют легко, удобно, безопасно, bla-bla-bla пользоваться API.

Итого, как ни странно, но ldap_search_ex() - один из самых разумных методов обсуждаемого
API.