Здравствуйте, Кирпа В.А., Вы писали:

_>>немного непонятная притензий для меня, это "кривоватая" реализация
_>>помогла вам найти и исправить ошибку
КВА>Так ошибки не было Ну подумаеш два раза закрыли файл

Ошибка была.

КВА>Для надежности

За такую "надежность" гнать надо тряпками, пропитанными известной жидкостью. Давайте еще для надежности два-три раза insert в sql делать — мало ли...

Здравствуйте, Кирпа В.А., Вы писали:

ДД>>Допустим, программа открывает файл f1, получает как результат указатель p1. fopen() добавляет этот указатель в список валидных. Программа работает с ним, потом закрывает. fclose() закрывает f1 и удаляет p1 из списка. Программа открывает другой файл f2, указатель возвращается численно равный p1 (ну, аллокатор так вернул). Потом следует повторное закрытие f1 и работа с f2. Каковы будут последствия?

КВА>Никаких
КВА>Работа с f2 уже невозможна потому что он закрыт Любая работа с файлом не только fclose (но и fprintf и т д) идут через валидацию указателя на файл

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

Здравствуйте, Kemm, Вы писали:

K>Здравствуйте, Кирпа В.А., Вы писали:

_>>>немного непонятная притензий для меня, это "кривоватая" реализация
_>>>помогла вам найти и исправить ошибку
КВА>>Так ошибки не было Ну подумаеш два раза закрыли файл

K>Ошибка была.

КВА>>Для надежности

K>За такую "надежность" гнать надо тряпками, пропитанными известной жидкостью. Давайте еще для надежности два-три раза insert в sql делать — мало ли...

Ты наверное юмора не понимаеш? "Для надежности" это надо читать в кавычках

Здравствуйте, Кирпа В.А., Вы писали:

КВА>Так ошибки не было Ну подумаеш два раза закрыли файл

Ну с точки зрения человека не связанного с миром компьютеров да,
если закрыть два раза, скажем, книгу, то она будет закрыта и ничего не случиться.

Каждый вызов fclose это неявный вызов fflush в соотвествие со стандартом,
что случится при вызове fflush с невалидным указателем бог знает.

Да в стандарте предусмотрена "EBADF",

но почему вы думаете что проблемма с криво написанными программами должна решаться на уровне системных
библиотек, а не на уровне самой программы?

КВА>>>Вывод: реализация библиотеки ввода/вывода в Linux — кривовата
ДД>>В данном случае реализация библиотеки критична к грубым ошибкам в приложении.

Пользуйтесь, например, stream'ом. Всяко проще.

кстати:

The behaviour of fclose() is undefined if the stream parameter is an
illegal pointer, or is a descriptor already passed to a previous invo-
cation of fclose().

(man 3 fclose)

Мне кажется, что под Solaris это Вам исключительно повезло, что оно не упало по SegFault. Потому как в любом случае free для структуры должен делаться. А два раза delete одного указателя... как оно на разных платформах (Solaris'а у меня под рукой, увы, нет, проверить не могу).

Здравствуйте, Кирпа В.А., Вы писали:

КВА>Так ошибки не было Ну подумаеш два раза закрыли файл
КВА>Для надежности

???

Почему бы тогда не писать

  int a;
  ...
  a = 1;
  a = 1;

...для надежности.

КВА>Так нет эту оплошность разработчики библиотеки ввода-вывода умудрились
КВА>преобразовать в Segmentation fault
КВА>

Каждая кривая программа должна получить Segmentation fault! Это намного лучше, чем незаметная потеря данных.

Здравствуйте, Черепнин Сергей, Вы писали:



КВА>>Покатим бочку на Linux дальше
КВА>>Это же как надо тупо реализовать библиотечные функции ввода/вывода
КВА>>чтобы повторное закрытие файла ломало heap
КВА>>кстати повторное закрытие файла в SUN, Windows ничего вредного не делает

ЧС> В Windows они ничего вредного не делают, потому что как я предполагаю, все эти функции реализованы через CreateFile(), CloseHandle(). А когда им передать неправильный хэндл, они его просто не находят в таблице открытых хэндлов и всё. В Линуксе наверно никаких таблиц нет, функция просто работает с указателем, считая
ЧС>его правильным по умолчанию.

В Линуксе работа ведется так же через хендел, и его можно получить вызовом fileno

Здравствуйте, mr_jek, Вы писали:

_>Да в стандарте предусмотрена "EBADF",

ERRORS
EBADF The file descriptor underlying fp is not valid.

Здравствуйте, Кирпа В.А., Вы писали:

The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.

NAME
fclose — close a stream
...

DESCRIPTION
...
[CX] [Option Start] The fclose() function shall mark for update the st_ctime and st_mtime fields of the underlying file, if the stream was writable, and if buffered data remains that has not yet been written to the file. The fclose() function shall perform the equivalent of a close() on the file descriptor that is associated with the stream pointed to by stream. [Option End]
...
After the call to fclose(), any use of stream results in undefined behavior.

кроме того:

The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.

NAME
close — close a file descriptor
DESCRIPTION
The close() function shall deallocate the file descriptor indicated by fildes. To deallocate means to make the file descriptor available for return by subsequent calls to open() or other functions that allocate file descriptors. All outstanding record locks owned by the process on the file associated with the file descriptor shall be removed (that is, unlocked).
...

When all file descriptors associated with an open file description have been closed, the open file description shall be freed.
...

Здравствуйте, Кирпа В.А., Вы писали:

КВА>Покатим бочку на Linux дальше
КВА>Это же как надо тупо реализовать библиотечные функции ввода/вывода
КВА>чтобы повторное закрытие файла ломало heap
КВА>кстати повторное закрытие файла в SUN, Windows ничего вредного не делает

Линух то тут причеи, там с файлами работают через open, close, read, write.

Реализация fopen, fclose зависит от того какой ты компилятор используешь,
вернеет от поставляемой вместе с ним реализация стандартной библиотеки. Если тебя
что то не устраивает, пиши авторам этой самой библиотеки.

Здравствуйте, Dair, Вы писали:


D>кстати:

D>

D>The behaviour of fclose() is undefined if the stream parameter is an
D>illegal pointer, or is a descriptor already passed to a previous invo-
D>cation of fclose().

D>(man 3 fclose)

D>Мне кажется, что под Solaris это Вам исключительно повезло, что оно не упало по SegFault. Потому как в любом случае free для структуры должен делаться. А два раза delete одного указателя... как оно на разных платформах (Solaris'а у меня под рукой, увы, нет, проверить не могу).

Вам не кажется, а Вы абсолютно правы, я цитировал IEEE Std 1003.1, 2004 (POSIX)
здесь

Автор: srggal
Дата: 12.12.05

On Mon, 12 Dec 2005 13:02:07 -0000, voxel3d <20383@users.rsdn.ru> wrote:

> ME>Сиди в виндозе и радуйся жизни.
>
> Грубить-то зачем? После подобных ответов окружающие начинают к юниксоидам относиться как красноглазым пионерам.

Грубости не было.

> ME>Лучше пусть они маскируют ошибки в твоем коде, так?
>
> Тем более, что выдвинутый тобою тезис, сводящийся к тому, что в операционной системе всякого рода защита от кривых приложений — вещь ненужная, не выдерживает никакой критики.

Что за критика такая?

В Linux ты не обрушишь kernel, он защищен от кривых рук, свое же приложение — пожалуйста.

--
Maxim Yegorushkin

On Mon, 12 Dec 2005 13:34:42 -0000, Кирпа В.А. <5450@users.rsdn.ru> wrote:

[]

> Я веду к тому что в библиотеке ввода/вывода необходим список открытых файлов
> что-то типа std::vector<FILE *>
> в который fopen добавляет а fclose удаляет
> Тогда проверка на валидность указателя FILE * элементарна

Мне он не нужен, я не хочу платить за это. Если тебе это нужно — заведи для своего приложения.

--
Maxim Yegorushkin

Здравствуйте, MaximE, Вы писали:


ME>Что за критика такая?

ME>В Linux ты не обрушишь kernel, он защищен от кривых рук, свое же приложение — пожалуйста.

ЗАПРОСТО, в своём модуле, в контексте прерывания засну
И вот она ловещая паника ядра

On Mon, 12 Dec 2005 16:38:50 -0000, srggal <21794@users.rsdn.ru> wrote:

> ME>Что за критика такая?
>
> ME>В Linux ты не обрушишь kernel, он защищен от кривых рук, свое же приложение — пожалуйста.
>
> ЗАПРОСТО, в своём модуле, в контексте прерывания засну
> И вот она ловещая паника ядра

Мы говорим про приложение, не про модуль ядра.

--
Maxim Yegorushkin

Кирпа В.А. wrote:
>
> Ну вот и начался конструктивный диалог
> Я веду к тому что в библиотеке ввода/вывода необходим список открытых
> файлов
> что-то типа std::vector<FILE *>
> в который fopen добавляет а fclose удаляет
> Тогда проверка на валидность указателя FILE * элементарна

Проблема с файлами — частный случай проблемы с аллокацией памяти в C.
Постоянные проверки снизили бы эффективность. А зачем тогда вообще нужна
ручная аллокация, если плевать на эффектовность?

Кстати, отладочные версии библиотек для работы с памятью существуют. Они
проверяют все, что надо.

> Вывод: реализация библиотеки ввода/вывода в Linux — кривовата

А при чем здесь Linux? Это не Linux, а ANSI C. С тем, что C это не язык
для идиотов, спорить не буду. Для идиотов существует Visual Basic

Здравствуйте, MaximE, Вы писали:

ME>On Mon, 12 Dec 2005 16:38:50 -0000, srggal <21794@users.rsdn.ru> wrote:

>> ME>Что за критика такая?
>>
>> ME>В Linux ты не обрушишь kernel, он защищен от кривых рук, свое же приложение — пожалуйста.
>>
>> ЗАПРОСТО, в своём модуле, в контексте прерывания засну
>> И вот она ловещая паника ядра

ME>Мы говорим про приложение, не про модуль ядра.

Дык просото к слову пришлось

ИМХО фраза пафосная про "не обрушишь kernel" вот и не сдержался, благо — дурацкое дело не хитрое, и сам, допустил подобный баг по неграмотности

D>>Мне кажется, что под Solaris это Вам исключительно повезло, что оно не упало по SegFault. Потому как в любом случае free для структуры должен делаться. А два раза delete одного указателя... как оно на разных платформах (Solaris'а у меня под рукой, увы, нет, проверить не могу).

S>Вам не кажется, а Вы абсолютно правы, я цитировал IEEE Std 1003.1, 2004 (POSIX)
S>здесь

Автор: srggal
Дата: 12.12.05

После того, как я (сравнительно недавно) увидел MSVC, я познал сомнение

Не все компиляторы следуют стандартам

Здравствуйте, Dair, Вы писали:

D>

D>После того, как я (сравнительно недавно) увидел MSVC, я познал сомнение

D>Не все компиляторы следуют стандартам

ГМ, уже много раз упоминалось, даже лично мной на грабли натыкалось, что правильная работа это частный случай UB

ЗЫ
Даже ориджин у кого-то на форуме есть такой

Здравствуйте, Кирпа В.А., Вы писали:

КВА>>>Для надежности
K>>За такую "надежность" гнать надо тряпками, пропитанными известной жидкостью. Давайте еще для надежности два-три раза insert в sql делать — мало ли...
КВА>Ты наверное юмора не понимаеш? "Для надежности" это надо читать в кавычках

Я так и прочитал, если обратить внимание на выделенное.

Считать, что система должна (кому?!) отслеживать криворуких программистов — путь в никуда. Именно это Вы и декларировали в первых постах.
Следующее утверждение, например, почему при использовании gethostbyname() возникает такая "фигня" в multithread софте. Нафиг-нафиг-нафиг такие претензии. Никто не общал, что fclose() будет себя корректно вести в подобной ситуации. Ни стандарт Сей, ни POSIX, ни SUSv3.