Здравствуйте, srggal, Вы писали:
ME>>Мы говорим про приложение, не про модуль ядра.
S>Дык просото к слову пришлось
S>ИМХО фраза пафосная про "не обрушишь kernel" вот и не сдержался, благо — дурацкое дело не хитрое, и сам, допустил подобный баг по неграмотности
Слава богу, модуль ядра нельзя загрузить из-под не-рута. А рутом систему можно изрушить и менее изощренными способами.
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Здравствуйте, srggal, Вы писали:
ME>>>Мы говорим про приложение, не про модуль ядра.
S>>Дык просото к слову пришлось
S>>ИМХО фраза пафосная про "не обрушишь kernel" вот и не сдержался, благо — дурацкое дело не хитрое, и сам, допустил подобный баг по неграмотности
AA>Слава богу, модуль ядра нельзя загрузить из-под не-рута. А рутом систему можно изрушить и менее изощренными способами.
Кирпа В.А. wrote:
> Здравствуйте, ДимДимыч, Вы писали: > > > ДД>Не забывайте, что FILE — это структура, и fopen() распределяет память > под нее, а fclose() освобождает. При повторном вызове fclose аргумент уже > указывает неизвестно на что и close(2) не может даже прочитать значение > дескриптора. close(2), кстати, корректно возвращает "Bad file descriptor". > ДД>Или вы предлагаете при каждом free() делать проверку на валидность > блока? > > Ну вот и начался конструктивный диалог > Я веду к тому что в библиотеке ввода/вывода необходим список открытых > файлов что-то типа std::vector<FILE *> > в который fopen добавляет а fclose удаляет > Тогда проверка на валидность указателя FILE * элементарна > > Вывод: реализация библиотеки ввода/вывода в Linux — кривовата.
В высшей степени странное утверждение! Функция glibc fclose соответствует
стандарту ANSI C, и в манах черным по белому написано, что ее поведение не
определено в случае передачи ей инвалидного указателя (что, кстати,
полностью соответствует стандарту).
Вообще непонятно, как ты хочешь обрабатывать передачу инвалидного УКАЗАТЕЛЯ
функции, на нем что написано, что он кривой.
Рекомендую читать маны, особенно по системным вызовам open, close, и
не ...здеть о том, что "реализация библиотеки ввода/вывода в Linux —
кривовата".
mr_jek wrote:
> Каждый вызов fclose это неявный вызов fflush в соотвествие со стандартом, > что случится при вызове fflush с невалидным указателем бог знает.
Ничего не должно произойти, если, конечно, fflush не скормить кривой
указатель (fflush использует fsync, который принимает файловый дескриптор,
а "плохие" дескрипторы обрабатываются).
> Да в стандарте предусмотрена "EBADF"
Только одна проблема, EBADF отдает close, а не fclose. Функции close
передается ИМЕННО ДЕСКРИПТОР, а не указатель на структуру, как в случае с
fclose. И, насколько я знаю, повторный вызов close для одного и того же
дескриптора совсем не страшен.
Здравствуйте, cattus, Вы писали:
C>В высшей степени странное утверждение! Функция glibc fclose соответствует C>стандарту ANSI C, и в манах черным по белому написано, что ее поведение не C>определено в случае передачи ей инвалидного указателя (что, кстати, C>полностью соответствует стандарту).
В данном случае соответсвие стандарту вряд ли можно назвать плюсом.
C>Вообще непонятно, как ты хочешь обрабатывать передачу инвалидного УКАЗАТЕЛЯ функции, на нем что написано, что он кривой.
А подумать, прежде чем писать можно было? Ей передаётся не абы какой указатель, а выделенный fopen. Что мешает хранить где-то внутри список всех указателей выделенных fopen и при вызове fread, fwrite, fclose проверять валидность переданного указателя простым его вхождением в список? Ничего не мешает, кроме лени и желания гнать понты. По сравнению со скоростью ввода-вывода это копейки. Те же дескрипторы в Windows это сплошь указатели или индексы в таблицах, однако использование левого дескриптора не приводит ни к какому краху. UB на сегодня это плохой тон или детский сад, уж сам выбери.
C>Рекомендую читать маны, особенно по системным вызовам open, close, и не ...здеть о том, что "реализация библиотеки ввода/вывода в Linux — кривовата".
Рекомендую думать, что говоришь и как говоришь. О того что кто-то в твойм понимании пи@@ит твои слова не стали весомее, а мысли умнее.
A>А подумать, прежде чем писать можно было? Ей передаётся не абы какой указатель, а выделенный fopen. Что мешает хранить где-то внутри список всех указателей выделенных fopen и при вызове fread, fwrite, fclose проверять валидность переданного указателя простым его вхождением в список?
Как Вы представляете работу какго-нибудь сервера собранного с такой библиотекой? Будет непрекращающаяся утечка памяти.
Здравствуйте, LelicDsp, Вы писали:
LD>Как Вы представляете работу какго-нибудь сервера собранного с такой библиотекой? Будет непрекращающаяся утечка памяти.
С какой стати? Надеюсь понятно, что внутри fclose указатель будет из списка удалятся?
A>А подумать, прежде чем писать можно было? Ей передаётся не абы какой указатель, а выделенный fopen. Что мешает хранить где-то внутри список всех указателей выделенных fopen и при вызове fread, fwrite, fclose проверять валидность переданного указателя простым его вхождением в список?
Кстати, я правильно понимаю, что аналогичную логику нужно будет реализовать в malloc/free, opendir/closedir, и еще в куче других функций, которые аллоцируют память?
On Thu, 15 Dec 2005 16:26:55 -0000, adontz <2053@users.rsdn.ru> wrote:
> C>В высшей степени странное утверждение! Функция glibc fclose соответствует > C>стандарту ANSI C, и в манах черным по белому написано, что ее поведение не > C>определено в случае передачи ей инвалидного указателя (что, кстати, > C>полностью соответствует стандарту). > > В данном случае соответсвие стандарту вряд ли можно назвать плюсом.
Лично меня такое поведение устраивает на 100%.
> C>Вообще непонятно, как ты хочешь обрабатывать передачу инвалидного УКАЗАТЕЛЯ функции, на нем что написано, что он кривой. > > А подумать, прежде чем писать можно было? Ей передаётся не абы какой указатель, а выделенный fopen. Что мешает хранить где-то внутри список всех указателей выделенных fopen и при вызове fread, fwrite, fclose проверять валидность переданного указателя простым его вхождением в список? Ничего не мешает, кроме лени и желания гнать понты. По сравнению со скоростью ввода-вывода это копейки.
Лишний footprint только для того, чтобы горстка наивных программистов не раздувала флейм в группах?
Я не хочу платить за то что не использую. Уверен, что большинство зрелых программистов думают также.
Разгребайте баги в своем коде специализированными тулзами, коих навалом бесплатно.
> Те же дескрипторы в Windows это сплошь указатели или индексы в таблицах, однако использование левого дескриптора не приводит ни к какому краху. UB на сегодня это плохой тон или детский сад, уж сам выбери.
Дескрипторы в Windows можно сравнивать с файловыми дескрипторами Unix, но не объектами FILE стандартной библиотеки.
Здравствуйте, LelicDsp, Вы писали:
LD>Кстати, я правильно понимаю, что аналогичную логику нужно будет реализовать в malloc/free, opendir/closedir, и еще в куче других функций, которые аллоцируют память?
opendir/closedir — да
malloc/free — есть более эффективные решения. Но да, суть та же. В Windows функция HeapFree с ума не сходит если ей передать мусор.
adontz wrote:
> В данном случае соответсвие стандарту вряд ли можно назвать плюсом.
)
> А подумать, прежде чем писать можно было? Ей передаётся не абы какой > указатель, а выделенный fopen. Что мешает хранить где-то внутри список > всех указателей выделенных fopen и при вызове fread, fwrite, fclose > проверять валидность переданного указателя простым его вхождением в > список? Ничего не мешает, кроме лени и желания гнать понты. По сравнению > со скоростью ввода-вывода это копейки. Те же дескрипторы в Windows это > сплошь указатели или индексы в таблицах, однако использование левого > дескриптора не приводит ни к какому краху. UB на сегодня это плохой тон > или детский сад, уж сам выбери.
"А подумать, прежде чем писать можно было?" ) Как по твоему должен
работать grep, который вынужден потенциально открывать ОООЧЕНЬ МНОГО
файлов? Eсли после выделения памяти для структуры FILE fopen'om, fclose не
будет освобождать эту память, то память будет "утекать". На 32-x битной
архитектуре sizeof(FILE) == 148, несложно подсчитать сколько потребуется
памяти для хранения FILE для УЖЕ ЗАКРЫТЫХ дескрипторов -- для 1000000 УЖЕ
ЗАКРЫТЫХ файлов потребуется 141 МБ (!), плюс для хранения указателей на
FILE 3 МБ, итого 144 МБ.
> Рекомендую думать, что говоришь и как говоришь. О того что кто-то в твойм > понимании пи@@ит твои слова не стали весомее, а мысли умнее."
LD>>Как Вы представляете работу какго-нибудь сервера собранного с такой библиотекой? Будет непрекращающаяся утечка памяти.
A>С какой стати? Надеюсь понятно, что внутри fclose указатель будет из списка удалятся?
Ок, согласен, можно было бы держать список валидных указателей. Стормозил. Но его придется делать потокобезопасным, делать для всех пар подобных функций... И чего добьемся в результате? Программы с трудные для отладки, с плохоповторяемым поведением...
Здравствуйте, MaximE, Вы писали:
ME>Лишний footprint только для того, чтобы горстка наивных программистов не раздувала флейм в группах?
Ты все свои программы написал без ошибок?
ME>Я не хочу платить за то что не использую. Уверен, что большинство зрелых программистов думают также.
Я не вижу чему тут сопротивлятся. Ну будет fclose что-то проверять в то время как ты будешь всегда передавать правильный указатель. И что?
ME>Разгребайте баги в своем коде специализированными тулзами, коих навалом бесплатно.
Максим, ты давно коммерческий софт разрабатывал? Релизы всегда выходят совсем безбажные?
Можно сколько угодно теоретизировать по поводу плохих программистов не умеющих отлаживать код, намекая при этом что ты сам не такой. На приктике же, подобная функциональность никого не стесняя может оказатся весьма полезной.
>> Те же дескрипторы в Windows это сплошь указатели или индексы в таблицах, однако использование левого дескриптора не приводит ни к какому краху. UB на сегодня это плохой тон или детский сад, уж сам выбери.
ME>Дескрипторы в Windows можно сравнивать с файловыми дескрипторами Unix, но не объектами FILE стандартной библиотеки.
Почему? Объяснишь великую разницу из-за которой возможное для дескрипторов, для указателей на FILE не выозможно.
Здравствуйте, LelicDsp, Вы писали:
LD>Но его придется делать потокобезопасным,
Это хорошо проработанная задача. Делается даже без блокировок.
LD>делать для всех пар подобных функций...
А их разве очень много? и потом, никто не говорил что дуракоустойчивую библиотеку написать так же легко.
LD>И чего добьемся в результате? Программы с трудные для отладки, с плохоповторяемым поведением...
Пояснишь? А то я не понял из чего ты сделал вывод о трудноотлаживаемости.
Здравствуйте, cattus, Вы писали:
C>"А подумать, прежде чем писать можно было?" ) Как по твоему должен C>работать grep, который вынужден потенциально открывать ОООЧЕНЬ МНОГО C>файлов? Eсли после выделения памяти для структуры FILE fopen'om, fclose не C>будет освобождать эту память, то память будет "утекать". На 32-x битной C>архитектуре sizeof(FILE) == 148, несложно подсчитать сколько потребуется C>памяти для хранения FILE для УЖЕ ЗАКРЫТЫХ дескрипторов -- для 1000000 УЖЕ C>ЗАКРЫТЫХ файлов потребуется 141 МБ (!), плюс для хранения указателей на C>FILE 3 МБ, итого 144 МБ.
Повторюсь специально для тебя. fclose удаляет указатель из списка валидных. Зачем хранить 1000000 значений указателей для УЖЕ ЗАКРЫТЫХ файлов я не очень понимаю.
