Безопасно ли называть dlclose(NULL)?

Question

Безопасно ли называть dlclose(NULL)?

Я испытываю сбой, когда я прохожу null указатель на dlclose,

Должен ли я проверить на ноль перед звонком dlclose?

POSIX ничего не говорит об этом: http://pubs.opengroup.org/onlinepubs/7908799/xsh/dlclose.html

Это неопределенное поведение или ошибка в dlclose реализация?

6

linux shared-libraries posix dynamic-library dynamic-loading

Источник

user99024 10 июл '12 в 12:05

3 ответа

Другие вопросы по тегам linux shared-libraries posix dynamic-library dynamic-loading

user166749 10 июл '12 в 12:19 2012-07-10 12:19 · Answer 1 · 2012-07-10 12:19

Это сложно. POSIX утверждает, что

если handle не относится к открытому объекту, dlclose() возвращает ненулевое значение

из которого можно сделать вывод, что для произвольного указателя он должен определить, относится ли этот указатель к открытому объекту. Версия для Linux/Glibc, по-видимому, не выполняет такую проверку, поэтому вы захотите проверить NULL сам.

[Кроме того, справочная страница Linux также не очень полезна. Это неявно о libdl поведение функций, откладывание до POSIX без очень четкого заявления о соответствии.]

user499609 10 июл '12 в 12:20 2012-07-10 12:20 · Answer 2 · 2012-07-10 12:20

Это также ничего не говорит о принятии NULL и не врезаться. Мы можем предположить из вашего теста, что он не делает явного NULL проверьте, и он должен каким-то образом использовать указатель для выполнения действия закрытия... так что у вас есть.

1

Источник

user499609 10 июл '12 в 12:20

user877329 03 июл '15 в 09:38 2015-07-03 09:38 · Answer 3 · 2015-07-03 09:38

После malloc/free Соглашение (1), это ошибка. Если это следует fopen/fclose конвенция (2) это не так. Так что, если есть ошибка, она есть в стандарте, потому что в ней отсутствует соглашение по работе с зомби.

Соглашение (1) хорошо работает с семантикой перемещения C++11
Конвенция (2) оставляет большую ответственность за вызывающего абонента. В частности, dtor должен явно проверить на ноль, была ли выполнена операция перемещения.

Я думаю, что это то, что должно быть пересмотрено для предстоящей редакции POSIX, чтобы избежать путаницы.

Обновить

Я нашел из этого ответа https://stackru.com/a/6277781/877329, а затем читал man pthread_join что вы можете позвонить pthread_join с недействительным тид, поддерживая malloc/free convension. Еще одна проблема, которую я обнаружил с динамическим интерфейсом загрузчика, заключается в том, что он не использует стандартную систему обработки ошибок, но имеет свою собственную dlerrorфункция.