Использование fclose для трубы попена является серьезной ошибкой?

Question

Несколько месяцев назад я пишу приложение CGI для Linux, которое использует popen() для чтения вывода команды, а затем я закрываю трубку с помощью fclose().

Теперь я читал, что для закрытых труб необходимо использовать pclose().

Руководство говорит:

Возвращаемое значение popen() нормальный поток стандартный I/O во всех отношениях кроме того, что она должна быть закрыта с pclose(), а не fclose(3).

Мой код выглядит так:

if ((NULL != (f = popen(command.value, "r")))) { 
    //do something 
    fclose(f); 
} 

Мой вопрос:

Моя ошибка есть проблемы безопасности? Эта программа в настоящее время находится в производстве. В тестах это ничего не делает. Действительно необходимо, исправить его, используя pclose() вместо fclose()? Примечание. Я только открываю PIPE один раз в программе.

Сегодня, в моем местном доме, я делаю некоторые испытания и fclose() и pclose() не возвращает EOF, указывающий сбой.

Answer 1

Если вы используете fclose на трубе, у вас будет утечка дескриптора файла, так как fclose не освободит указатель файла в ядре (который создается при создании канала с момента его создания).

Пока ваше тестирование пока не показало каких-либо проблем, запустите программу 3000 раз (или как можно разрешить многие файловые дескрипторы, по сравнению с встроенным ядром) и наблюдайте, когда вы больше не сможете создавать каналы ,

Answer 2

Согласно this thread, с использованием fclose вместо pclose означает, что процесс на другом конце трубы не получает, поэтому он остается зомбированным.

Answer 3

Я только что узнал (через 10 лет), что я ошибочно использовал fclose для некоторых popen звонков, работающих на серверах Windows 2008. Он работал (т. Е. Не разбился), и я все равно не интересовался кодом возврата на эти вызовы.

Но мне нужен код возврата последних popen поток, а закрытие было сделано правильно с pclose.

Это странный эффект возврата кода ошибки 0 (возможно, сбор кода возврата ранее не pclosed), даже если команда не удалась, создав очень странную ошибку в коде, что могло привести к катастрофическим ошибкам потому что вызывающий считает, что команда работала.

Так что это не только вопросы утечки дескрипторов, он может ввести функциональные ошибки в коде (даже если приложение работает в течение нескольких секунд, и вы не заботитесь о протекающих дескрипторах)