Здравствуйте, Kemm, Вы писали:
K>Вы-таки удивитесь, но встроенные системы — это не только смартфоны/КПК и прочие фоны. Да и вообще не они. 8))
Я и не предлагал втыкать кучу run-time проверок на девайсы с 32Кб памяти.
K>А Вы не подскажете компанию, в которой принят такой подход? Чтоб не купить ничего ненароком... K>Было у нас раньше примерно так же, по вине руководства, которое к программированию имело примерно столько же отношения, сколько я к ядерной энергетике. Кончилось, когда жареный петух клюнул и "дело запахло вазелином"(с). До сих пор вспоминаем эту эпохальную фразу начальника: "Зачем нам тестеры? И так все нормально...". С какими мыслями вспоминаем, приводить не буду по цензурным соображениям. До сих пор нормальное тестирование построить не можем, хотя легче стало намного. K>Да, ценность логов отрицать я не собираюсь, это просто-напросто глупо. Только не являются они серебряной пулей ни разу. Просто один из равноправных инструментов.
Я и не говорил, давайте вообще без тестеров. Я просто имею ввиду, что есть оишбки, которые никакие тестеры не поумают, потому что они только на том треклятом компьютере и проявляются. И тестеры тоже не являются серебряной пулей, сколько бы их не было. Более того, я регулярно пишу код который отклоняется от того или иного стандарта, зато совместим с существующим ПО, которое тоже отклоняется. Тут уже любые тестеры идут лесом — отладка только по логам.
Здравствуйте, adontz, Вы писали:
K>>Напиши обертку вокруг fopen()/fclose(), которая этим будет заниматься. Медленнее не будет, зато будет правильно. А то в лог писать... В какой лог, простите?.. A>Да хоть в файл. Хотя БД конечно лучше, но просто не всегда есть.
В файл? Ой, а у меня тут все read-only, и логи я в syslog пишу, какая незадача. Или еще куда. В последовательный порт. Чем обертка-то не устраивает.
Здравствуйте, adontz, Вы писали:
K>>Нет. Вай-вай-вай, какого черта вот в этом вот месте этот трижды проклятый someOS не соответствует стандарту? А, решили, что можно произвольно реализовывать все, а не только UB... A>Я говорил только об UB.
Следом было предложение писать из библотечной функции логи. Вот уже прямое несоответствие стандарту.
K>>Религия мне не позволяет считать свое видение проблемы единственно верным. И пока есть реализации, не соответствующие ему — кричать на всю ивановскую "кривизна". A>Пока что ты борешься за реализацию с никому не нужным UB.
Пока я борюсь за отсутствие необходимости усложнять. По мне, ошибка вылезшая в момент возникновения лучше ошибки, вылезшей через 5 минут. Проще оно в поимке и отладке. И, хотя второй fclose() приводит к SIGSEGV'у на нелюбимом мной линуксе, а на более приятных для меня ОС не приводит, я склоняюсь в пользу линуксовой реализации именно по этой причине.
Здравствуйте, adontz, Вы писали:
K>>Вы-таки удивитесь, но встроенные системы — это не только смартфоны/КПК и прочие фоны. Да и вообще не они. 8)) A>Я и не предлагал втыкать кучу run-time проверок на девайсы с 32Кб памяти.
Так. А как себя на этих девайсах должен вести fclose() в таком случае?.. Или мы в стандарте оставляем по старому, но гнобим всех, кто UB реализовал без проверок?
K>>Было у нас раньше примерно так же, по вине руководства, которое к программированию имело примерно столько же отношения, сколько я к ядерной энергетике. Кончилось, когда жареный петух клюнул и "дело запахло вазелином"(с). До сих пор вспоминаем эту эпохальную фразу начальника: "Зачем нам тестеры? И так все нормально...". С какими мыслями вспоминаем, приводить не буду по цензурным соображениям. До сих пор нормальное тестирование построить не можем, хотя легче стало намного. K>>Да, ценность логов отрицать я не собираюсь, это просто-напросто глупо. Только не являются они серебряной пулей ни разу. Просто один из равноправных инструментов. A>Я и не говорил, давайте вообще без тестеров. Я просто имею ввиду, что есть оишбки, которые никакие тестеры не поумают, потому что они только на том треклятом компьютере и проявляются. И тестеры тоже не являются серебряной пулей, сколько бы их не было. Более того, я регулярно пишу код который отклоняется от того или иного стандарта, зато совместим с существующим ПО, которое тоже отклоняется. Тут уже любые тестеры идут лесом — отладка только по логам.
Неоттестированный продукт продуктом не является. (с) Так что без тестеров идет лесом скорее такой "продукт".
Вы можете мне объяснить, чем вам не нравятся обертки вокруг f*()?
Здравствуйте, adontz, Вы писали:
LD>>>>Верится с трудом. A>>>http://www.google.com/search?q=lock+free+list LD>>Лень углубляться посмотрел несколько первых ссылок. Нигде настоящего lock-free списка не релиизована. Везде основываются на атомарность compare-and-swap. Ниже типичная цитата. Подавляющее большинство аппаратных архитектур такой роскоши не имеют. A>Проблемы не увидел. Для x86 это одна команда процессора. Обменять по условию 1, 2, 4 байт — CMPXCHG (поддерживается начиная c 486), 8 байт CMPXCHG8B (поддерживается начиная c Pentium I)
Hint: i86 не самое популярное семейство процессоров.
Здравствуйте, Kemm, Вы писали:
K>Следом было предложение писать из библотечной функции логи. Вот уже прямое несоответствие стандарту.
Где я такое сказал?
if(fclose(file) == EOF) log("what the f...?");
Ты сперва придумываешь за меня что-то, а потом доблесно с этим сражаешься. Зачем?
Здравствуйте, adontz, Вы писали:
K>>Следом было предложение писать из библотечной функции логи. Вот уже прямое несоответствие стандарту. A>Где я такое сказал? A>
A>if(fclose(file) == EOF) log("what the f...?");
A>
A>Ты сперва придумываешь за меня что-то, а потом доблесно с этим сражаешься. Зачем?
Тогда так и надо говорить, говорили-то про libc. Это разумно. Следующий шаг:
int
my_fclose(FILE *file)
{
if (!is_valid_file(file)) {
log("Attempt to close closed file");
return(EBADF);
}
delete_from_valid_files(file);
return fclose(file);
}
FILE *
my_fopen(const char *path, const char *mode)
{
FILE *file;
if ((file = fopen(path, mode)) != NULL) {
add_valid_file(file);
return file;
}
return NULL;
}
Чем это-то хуже, например? Благо, можно просто через LD_PRELOAD подсунуть обертку на fopen()/fclose(), если софт в бинарный...
Здравствуйте, Kemm, Вы писали:
K>Так. А как себя на этих девайсах должен вести fclose() в таком случае?.. Или мы в стандарте оставляем по старому, но гнобим всех, кто UB реализовал без проверок?
Честно говоря я себе очень слабо представляю какой F надо CLOSE если у тебя всего 32Кб. В любом случае разработка программ под такие устройства это совсем другой стиль.
K>Вы можете мне объяснить, чем вам не нравятся обертки вокруг f*()?
Ничем. Почти. Их надо таскать за собой из проекта в проект, когда можно было бы реализовать на уровне LIBC.
Здравствуйте, Kemm, Вы писали:
K>Hint: i86 не самое популярное семейство процессоров.
Не самое популярное где? Тогда уж назови самое популярное. Кстати позаботься, чтобы у самого популярного по твоей версии семейства не было аналога команды CMPXCHG
Здравствуйте, adontz, Вы писали:
K>>Hint: i86 не самое популярное семейство процессоров. A>Не самое популярное где? Тогда уж назови самое популярное. Кстати позаботься, чтобы у самого популярного по твоей версии семейства не было аналога команды CMPXCHG
Чтоб я помнил все ассемблеры. Мне достаточно того, что на ряде платформ нет. На arm'е есть? На sparc'е? По-моему, ни там, ни там.
Здравствуйте, adontz, Вы писали:
K>>Так. А как себя на этих девайсах должен вести fclose() в таком случае?.. Или мы в стандарте оставляем по старому, но гнобим всех, кто UB реализовал без проверок? A>Честно говоря я себе очень слабо представляю какой F надо CLOSE если у тебя всего 32Кб.
У-у-у... Про спектрумы уже и забыли... 8))
A>В любом случае разработка программ под такие устройства это совсем другой стиль.
И что? Будем два стандарта С держать?
K>>Вы можете мне объяснить, чем вам не нравятся обертки вокруг f*()? A>Ничем. Почти. Их надо таскать за собой из проекта в проект, когда можно было бы реализовать на уровне LIBC.
Хм... Великий труд — таскать с собой библиотечку из N функций... В любом случае, я вот как минимум всегда с собой таскаю реализацию strlcpy()/strlcat() из, afair, NetBSD. Просто потому, что это удобно.
А вот возражения против обязательной проверки в рамках libc уже озвучили, и не одно.
adontz wrote: > > А подумать, прежде чем писать можно было? Ей передаётся не абы какой > указатель, а выделенный fopen. Что мешает хранить где-то внутри список > всех указателей выделенных fopen и при вызове fread, fwrite, fclose > проверять валидность переданного указателя простым его вхождением в > список? Ничего не мешает, кроме лени и желания гнать понты. По сравнению > со скоростью ввода-вывода это копейки. Те же дескрипторы в Windows это > сплошь указатели или индексы в таблицах, однако использование левого > дескриптора не приводит ни к какому краху. UB на сегодня это плохой тон > или детский сад, уж сам выбери.
1) В Виндовсе тоже есть fopen(). С теми же самыми проблемами, как и в Линухе
2) Виндовсный handle'овый интерфейс к файлам надо сравнивать с
юниксовским интерфейсом, работающим через дескрипторы, а не с stdio
3) Стиль языка C заключается, в частности, в том, что библиотека и
компилятор доверяют программисту. Сказали fclose() два раза, значит
будем закрывать файл два раза. Сказали поделить на ноль, значит будем
делить на ноль. Для тех, кто не согласен с такой политикой, существуют
"безопасные" языки программирования. Там все, что надо, проверяется.
Платой за удобства обычно является потеря эффективности.
Kemm wrote: > > LD>>Но его придется делать потокобезопасным, > A>Это хорошо проработанная задача. Делается даже без блокировок. > > Ну-ка, ну-ка... Потокобезопасную реализацию fopen() со списком валидных > 'FILE *' в студию.
Строго говоря, в любой реализации этот список уже есть. Hint: exit()
обязана закрыть все файлы, открытые через fopen(). И при этом не забыть
сказать на них fflush().
Но тем не менее, это не значит, что fclose() _обязан_ проверять файл на
валидность.
Здравствуйте, Kemm, Вы писали:
K>Чтоб я помнил все ассемблеры. Мне достаточно того, что на ряде платформ нет. На arm'е есть? На sparc'е? По-моему, ни там, ни там.
Как тут же заметили список уже есть. Осталось им только воспользоватся.
Здравствуйте, Pzz, Вы писали:
>> LD>>Но его придется делать потокобезопасным, >> A>Это хорошо проработанная задача. Делается даже без блокировок. >> Ну-ка, ну-ка... Потокобезопасную реализацию fopen() со списком валидных >> 'FILE *' в студию.
Pzz>Строго говоря, в любой реализации этот список уже есть. Hint: exit() Pzz>обязана закрыть все файлы, открытые через fopen(). И при этом не забыть Pzz>сказать на них fflush().
Она обязана закрыть вообще все открытые файлы, не важно. Мне куда более в этот момент интересна переносимая реализация потокобезопасного fopen() со списком валидных файлов, не использующая блокировок. 8))
Pzz>Но тем не менее, это не значит, что fclose() _обязан_ проверять файл на Pzz>валидность.
Здравствуйте, Pzz, Вы писали:
Pzz>3) Стиль языка C заключается, в частности, в том, что библиотека и компилятор доверяют программисту. Сказали fclose() два раза, значит будем закрывать файл два раза. Сказали поделить на ноль, значит будем делить на ноль. Для тех, кто не согласен с такой политикой, существуют "безопасные" языки программирования. Там все, что надо, проверяется. Pzz>Платой за удобства обычно является потеря эффективности.
Я как бы не очень понял, почему политика библиотеки LIBC это свойство языка С и почему нельзя внести обсуждаемое изменение, если оно никак не влияет на существующие программы и не мешает диагностировать ошибки (они скрываются, просто больше не приводят к фатальным последствиям).
Я не прошу изменить стандарт, я спрашиваю чем это было бы плохо? Да можно это сделать и в виде обёрток, но как оказалось список уже есть, так зачем строить второй, когда уже есть готовый?
Здравствуйте, Kemm, Вы писали:
K>И что? Будем два стандарта С держать?
Я стандарт менять не собирался
K>Хм... Великий труд — таскать с собой библиотечку из N функций... В любом случае, я вот как минимум всегда с собой таскаю реализацию strlcpy()/strlcat() из, afair, NetBSD. Просто потому, что это удобно.
Как тут заметили список уже есть. Если писать обёртки, то мы зачем-то будет иметь два списка.
K>А вот возражения против обязательной проверки в рамках libc уже озвучили, и не одно.
Это когда вы думали, что я из библиотечно функции буду в логи писать. Или я что-то упустил?
Здравствуйте, Kemm, Вы писали:
K>Она обязана закрыть вообще все открытые файлы, не важно. Мне куда более в этот момент интересна переносимая реализация потокобезопасного fopen() со списком валидных файлов, не использующая блокировок. 8))
Полностью переносимой конечно же нет. На каких-то процессорах потребуются блокировки.
Pzz>>Но тем не менее, это не значит, что fclose() _обязан_ проверять файл на валидность. K>Угу. Что и пытаемся доказать.
Я и не говорю, что объязан. Я говорю — было бы очень неплохо.
Здравствуйте, adontz, Вы писали:
K>>Она обязана закрыть вообще все открытые файлы, не важно. Мне куда более в этот момент интересна переносимая реализация потокобезопасного fopen() со списком валидных файлов, не использующая блокировок. 8)) A>Полностью переносимой конечно же нет. На каких-то процессорах потребуются блокировки.
Именно поэтому не интересно.
Pzz>>>Но тем не менее, это не значит, что fclose() _обязан_ проверять файл на валидность. K>>Угу. Что и пытаемся доказать. A>Я и не говорю, что объязан. Я говорю — было бы очень неплохо.
Ну так было бы неплохо, например, иметь strlcpy()/strlcat() везде. "Везде" включает в себя стандарт. Так же было бы неплохо иметь там же [v]asprintf(). Ну так я же не называю системы, где нет перечисленного, кривыми в плане реализации libc?
Здравствуйте, Kemm, Вы писали:
K>Ну так было бы неплохо, например, иметь strlcpy()/strlcat() везде. "Везде" включает в себя стандарт. Так же было бы неплохо иметь там же [v]asprintf(). Ну так я же не называю системы, где нет перечисленного, кривыми в плане реализации libc?
Если ты не заметил, то я отвечал на это
В высшей степени странное утверждение! Функция glibc fclose соответствует стандарту ANSI C, и в манах черным по белому написано, что ее поведение не определено в случае передачи ей инвалидного указателя (что, кстати, полностью соответствует стандарту).
Вообще непонятно, как ты хочешь обрабатывать передачу инвалидного УКАЗАТЕЛЯ функции, на нем что написано, что он кривой.
И просто показал, что функция никак не противореча стандарту может устойчиво распознавать невалидные указатели. Вот и всё. А то что LIBC кривая, это ты меня с кем-то перепутал.
