Я просматривал исходный код SVN и нашел этот комментарий в исходном коде.
/* The following makes sure that file descriptors 0 (stdin), 1
(stdout) and 2 (stderr) will not be "reused", because if
e.g. file descriptor 2 would be reused when opening a file, a
write to stderr would write to that file and most likely
corrupt it. */
за которым следует этот код:
if ((fstat(0, &st) == -1 && open("/dev/null", O_RDONLY) == -1) ||
(fstat(1, &st) == -1 && open("/dev/null", O_WRONLY) == -1) ||
(fstat(2, &st) == -1 && open("/dev/null", O_WRONLY) == -1))
{
if (error_stream)
fprintf(error_stream, "%s: error: cannot open '/dev/null'\n",
progname);
return EXIT_FAILURE;
}
Я не понимаю, как «повторное использование» дескриптора файла может повредить файл. И как вы можете открыть файл с файловым дескриптором 2 (stderr)? И как открытие файла может повлиять на запись в stderr?
🤔 А знаете ли вы, что...
C оставался популярным и актуальным языком программирования на протяжении многих десятилетий.
Боюсь, я не знаю о проблемах, специфичных для SVN, для решения которых предназначен этот код (он был зафиксирован более 18 лет назад). Но я думаю, что приведенное ниже резюме описывает потенциальную проблему на высоком уровне. Поэтому я предполагаю, что рассматриваемая часть кода предотвращает это:
Давняя практика Unix требует, чтобы приложения запускались с стандартные потоки ввода, вывода и ввода/вывода ошибок в файловых дескрипторах 0, 1 и 2 соответственно. Предположение, что эти файловые дескрипторы будет правильно настроен, настолько силен, что большинство разработчиков даже не задумываются проверить их. Так что интересные вещи могут произойти, если приложение запускать с одним или несколькими закрытыми стандартными файловыми дескрипторами.
Рассмотрим, например, запуск программы с файловым дескриптором 2. закрыто. Следующему файлу, который откроет программа, будет присвоен этот дескриптор. Если что-то затем заставляет программу писать (что она думает, что это) стандартный поток ошибок, этот вывод вместо этого будет идти в другой файл, который был открыт, вероятно, повредив этот файл. А злонамеренный пользователь может легко натворить беспорядка таким образом; когда setuid программы вовлечены, потенциальные последствия хуже.
Взято с https://lwn.net/Articles/347815/
PS Проверьте svn вину за эту часть кода . В нем есть лог-сообщение, описывающее цель этих проверок.