Safe vs. unsafe - 2
От: klapaucius  
Дата: 01.06.06 12:01
Оценка: 112 (3) +1 -1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>На каком основании сделано предположение о том, что именно показанный пример будет меняться?


А на каком основании сделано предположение о том, что показанный пример НЕ БУДЕТ меняться?
Сколько не говори про сфероконей — а ведь то, что этот код никогда не изменится не доказать. Это невозможно в принципе.

ГВ>Хорошо, предположим, что строку форматирования поменяли...

ГВ>2. Каков характер предполагаемых изменений строкового литерала? На каком основании сделано предположение, что изменяющий строку не посмотрит на одну строчку вверх?

На каком основании сделано предположение о том, что изменяющий строку ПОСМОТРИТ на одну строчку вверх?
По сути — это делегирование ответственности тому, кто будет модифицировать код в будущем.
Вы считаете, что это хорошая практика?
Уж во всяком случае автор кода лучше в нем разбирается, не будет ли в таком случае лучше, чтобы именно автор заботился о том, чтобы этот код было легче модифицировать и при этом сложнее совершить ошибки?

ГВ>Это пока что фантомы (сферокони), прыгающие вокруг одного конкретного примера.


Сфероконей тут предостаточно, но боюсь, что все они Ваши.
Объясняю:

Вот что предлагает Дарней (я именно так его понял):

Если мы не можем решить задачу используя ТОЛЬКО safe средства — мы используем unsafe;
если же мы МОЖЕМ решить задачу используя ТОЛЬКО safe — то только такие средства и следует использовать.

Все просто, не так ли?

Следовательно:
если мы используем safe средства мы ничего не теряем. (Задача с использованием только таких средств решается)
если мы используем unsafe — мы теряем в надежности. Пусть даже только гипотетически.
Не кажется ли Вам, что при таком условии следует доказывать не то, что, например код будет изменяться, а то, что он изменяться не будет?
Да, мы, в каком-то смысле перестраховываемя, но ведь лучше перестраховаться, не так ли?

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

На самом деле, Дарнею вовсе не нужно доказывать, что что-то ОБЯЗАТЕЛЬНО случится.
Это Вам для опровержения его утверждения нужно доказать, что с кодом чего-то НИКОГДА не случиться.
Легко видеть, что такое утверждение Вы ни для произвольного, ни для приведенного в начале обсуждения кода не докажете.

Вместо этого приходится выслушивать истории про сферического программиста в вакууме, который обязательно посмотрит на одну строчку выше и решит все проблемы Вашего кода.
В реальной жизни таких сферопрограммистов не сыщешь.
Лично я считаю, что всецело полагаться на благоразумие окружающих — как минимум неблагоразумно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

03.06.06 04:29: Ветка выделена из темы ...и анекдот напоследок
Автор: AlexLion
Дата: 25.05.06
— VladD2
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re: Safe vs. unsafe - 2
От: Cyberax Марс  
Дата: 01.06.06 12:35
Оценка: +3 -1
klapaucius wrote:
> На каком основании сделано предположение о том, что изменяющий строку
> ПОСМОТРИТ на одну строчку вверх?
Элементарной компетентности. Можно сколько угодно делать безопасную
среду со всеми возможными проверками, но некомпетентный индус всегда
найдет способ сделать дырку.

За примерами — на thedailywtf.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re: Safe vs. unsafe - 2
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.06 14:08
Оценка: +4 -2 :)
Здравствуйте, klapaucius, Вы писали:

ГВ>>На каком основании сделано предположение о том, что именно показанный пример будет меняться?

K>А на каком основании сделано предположение о том, что показанный пример НЕ БУДЕТ меняться?
K>Сколько не говори про сфероконей — а ведь то, что этот код никогда не изменится не доказать. Это невозможно в принципе.

Нельзя доказать негативно сформулированный тезис.

Я сразу сформулирую свой основной тезис, чтобы было понятнее.


Любое средство защиты от чего-то служит для защиты от чего-то определённого. Соответственно, внедряя защиту какого-либо характера мы предотвращаем ту или иную вполне определённую группу ошибок. Однако, следует учесть, что множество только внутренних ошибок ограничено едва ли не множеством допустимых комбинаций идентификаторов. Следовательно, никакой код нельзя защитить ото всех возможных ошибок. Следовательно, для каждой конкретной задачи нужно выбирать оптимальную модель защиты от ошибок.



Ну а теперь — поехали дальше.

ГВ>>Хорошо, предположим, что строку форматирования поменяли...

ГВ>>2. Каков характер предполагаемых изменений строкового литерала? На каком основании сделано предположение, что изменяющий строку не посмотрит на одну строчку вверх?

K>На каком основании сделано предположение о том, что изменяющий строку ПОСМОТРИТ на одну строчку вверх?


С равным успехом можно перепутать последовательность идентификаторов в таком выражении:

String s = tagged(tag1, v1) + tagged(tag2, v2);


Так что, внимательность и понимание сути правок необходима программисту по-любому. Другое дело, что в силу определённых, зачастую привитых социумом, стереотипов ему может быть неприятно заботиться о тех или иных аспектах программы, но это уж вопрос о психоустойчивости... Однако, програмист по-прежнему должен "использовать внимательность".

K>По сути — это делегирование ответственности тому, кто будет модифицировать код в будущем.


Она в любом случае делегируется именно ему.

K>Вы считаете, что это хорошая практика?


Что такое "хорошая практика"?

K>Уж во всяком случае автор кода лучше в нем разбирается, не будет ли в таком случае лучше, чтобы именно автор заботился о том, чтобы этот код было легче модифицировать и при этом сложнее совершить ошибки?


Да, так будет лучше. Однако на момент разработки автор не всегда может даже предполагать, какие изменения с его кодом произойдут впоследствии. Образно выражаясь, вдруг кому-то из последователей придёт в голову прицепить плуг к подводной лодке, чтобы распахивать плантации морской капусты, а у неё стрингеры на это не рассчитаны? Так что, не разумно возлагать на автора ответственность за все возможные ошибки в последующих модификациях.

ГВ>>Это пока что фантомы (сферокони), прыгающие вокруг одного конкретного примера.

K>Сфероконей тут предостаточно, но боюсь, что все они Ваши.
K>Объясняю:
K>Вот что предлагает Дарней (я именно так его понял):

K>Если мы не можем решить задачу используя ТОЛЬКО safe средства — мы используем unsafe;


Угу, только это следствие из второго пункта.

K>если же мы МОЖЕМ решить задачу используя ТОЛЬКО safe — то только такие средства и следует использовать.


Слишком категоричное утверждение в силу наличия второй части. Напомню, что под safe в контексте нашей беседы подразумеваются функции, контролирующие использование буфера.

K>Все просто, не так ли?

K>Следовательно:

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

K>если мы используем safe средства мы ничего не теряем. (Задача с использованием только таких средств решается)


Мы теряем в читабельности кода и скорости исполнения. Это — как минимум. Поэтому следует заменить формулировку на: "...как правило, мы ничего не теряем".

K>если мы используем unsafe — мы теряем в надежности. Пусть даже только гипотетически.


Ключ: гипотетически.

K>Не кажется ли Вам, что при таком условии следует доказывать не то, что, например код будет изменяться, а то, что он изменяться не будет?


Нет. Этого доказать нельзя по определению и кроме того, само по себе условие содержит необоснованное допущение ("мы ничего не теряем" — теряем!). Можно только попытаться предсказать те или иные изменения с некоторой степенью достоверности.

K>Да, мы, в каком-то смысле перестраховываемя, но ведь лучше перестраховаться, не так ли?


Да, мы именно что перестраховываемся. То есть, вносим в программу функциональность, необходимость которой сомнительна. Лишняя перестраховка влечёт лишний объём кодирования, затрудняет отладку и т.п.

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


Это просто метафоры. А как по-Вашему, ещё можно обозначить сущности, которые появятся только с некоторой вероятностью? Например — будущие изменения?

K>На самом деле, Дарнею вовсе не нужно доказывать, что что-то ОБЯЗАТЕЛЬНО случится.


Разумеется. Это тоже недоказуемо. Однако, например, если на вход открытой библиотечной функции поступает простой const char*, то вполне разумно предположить, что он покажет невесть куда и невесть на что. Следовательно, в этом случае дополнительная защита на входе будет правомерной.

K>Это Вам для опровержения его утверждения нужно доказать, что с кодом чего-то НИКОГДА не случиться.


Нет, мой друг. Это доказать невозможно. Это даже утверждать-то нельзя. По отношению к своему примеру я утверждал несколько иное:

— сам по себе приведённый пример не влечёт UB или GPF;
— он компактен и легко модифицируется (всего пара строк).

Заметьте, я не пытался агитировать за применение такого подхода любой ценой.

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


Разумеется.

K>Вместо этого приходится выслушивать истории про сферического программиста в вакууме, который обязательно посмотрит на одну строчку выше и решит все проблемы Вашего кода.


От невнимательности программиста защиты не придумать.

K>В реальной жизни таких сферопрограммистов не сыщешь.


Меня уже сферопрограммистом называют? Внесу в реестр необычных характеристик меня лично, спасибо.

K>Лично я считаю, что всецело полагаться на благоразумие окружающих — как минимум неблагоразумно.


Всецело и на всех — не знаю. А вот на коллег по цеху — почему бы и нет?
<< Под музыку: Аквариум — Жёлтая луна >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Safe vs. unsafe - 2
От: klapaucius  
Дата: 02.06.06 12:00
Оценка: 41 (4) +1 -1 :))
Здравствуйте, Геннадий Васильев, Вы писали:

K>>Сколько не говори про сфероконей — а ведь то, что этот код никогда не изменится не доказать. Это невозможно в принципе.


ГВ>Нельзя доказать негативно сформулированный тезис.

О чем я и говорю.

ГВ>Я сразу сформулирую свой основной тезис, чтобы было понятнее.

ГВ>
Любое средство защиты от чего-то служит для защиты от чего-то определённого. Соответственно, внедряя защиту какого-либо характера мы предотвращаем ту или иную вполне определённую группу ошибок. Однако, следует учесть, что множество только внутренних ошибок ограничено едва ли не множеством допустимых комбинаций идентификаторов. Следовательно, никакой код нельзя защитить ото всех возможных ошибок. Следовательно, для каждой конкретной задачи нужно выбирать оптимальную модель защиты от ошибок.

ГВ>

ГВ>Ну а теперь — поехали дальше.

Дальше ехать нет никакой возможности, потому, что тезис этот понятности не добавляет и вот почему:
1) Вы в нем только и делаете, что определяете неопределенность через неопределенность. Понятно, что Вы устанавливаете соответствие между классом средств защиты и классом проблем, для защиты от которых они предназначены, но такое соответствие тривиально. Поймите, сказать что нужно выбирать оптимальную модель — ничего не сказать, ведь КРИТЕРИЙ ОПТИМАЛЬНОСТИ Вы не указали.
Вот у Дарнея критерий четко сформулирован: максимизация надежности при выполнении условий задачи, даже в том случае, если максимизация надежности в условиях задачи не оговорена.
А у Вас что? Ясной формулировки я не увидел. А при отсутствии ясно выраженного критерия Ваш тезис тезису Дарнея и не противоречит.
2) Другой недостаток заключается в том, что Вы утверждаете

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

делая после этого какие-то далеко идущие выводы. Понятно, что множество ошибок велико, однако дело в том, что ошибки эти не равновероятны. Я выдвигаю такую гипотезу: если провести статистический анализ ошибок, совершаемых программистами, то в большинстве случаев будут совершаться ошибки из некоторого ограниченного подмножества множества всех возможных ошибок.

Вот аналогия, которая, разумеется, ничего не доказывает, зато неплохо иллюстрирует:
Множество возможных смертей очень велико, онако из этого вовсе не следует, что не нужно уделять много сил заботе о здоровье сердца, на основании того, что защищать голову от падения метеоритов это очевидный для всех идиотизм. Ведь от сердечно-сосудистых заболеваний умерает, допустим 50% людей, а от попаданий метеоритов один человек за всю историю. Это просто логически некорректно.

Защитники safe средств считают, по видимому, что ошибки связанные с unsafe средствами как раз и относятся к подмножеству ошибок, совершаемых гораздо чаще прочих.

K>>На каком основании сделано предположение о том, что изменяющий строку ПОСМОТРИТ на одну строчку вверх?


ГВ>С равным успехом можно перепутать последовательность идентификаторов в таком выражении:


ГВ>
ГВ>String s = tagged(tag1, v1) + tagged(tag2, v2);
ГВ>


Ну вот, опять! Почему же с равным? Где данные о том, что вероятность такой ошибки приближенна равна вероятности ошибки с изменением формата строки?

ГВ>Так что, внимательность и понимание сути правок необходима программисту по-любому.


Несомненно. Однако, внимательность человека очень ограничена. Поэтому и необходимы средства автоматического контроля и средства повышения абстракции. Все для уменьшения нагрузки на внимательность.

ГВ>Другое дело, что в силу определённых, зачастую привитых социумом, стереотипов ему может быть неприятно заботиться о тех или иных аспектах программы, но это уж вопрос о психоустойчивости...


Боюсь, что дело тут не в стереотипах. Разные аспекты объективно неравнозначны. Я не могу доказать, что это так, но могу сказать, что ВЕРОЯТНОСТЬ того, что они равнозначны очень низка. Если у Вас другие данные — было бы интересно их увидеть. Однако, даже если аспекты СУБЪЕКТИВНО неравнозначны — это ничего по существу не меняет. Я считаю, что лучше подгонять инструмент под человека, а не человека под инструмент.

K>>По сути — это делегирование ответственности тому, кто будет модифицировать код в будущем.

ГВ>Она в любом случае делегируется именно ему.

В любом случае делегируется ЧАСТЬ ответственности. Не стоит устремлять эту часть к целому.

K>>Вы считаете, что это хорошая практика?

ГВ>Что такое "хорошая практика"?

Хорошая сферическая практика в вакууме — это практика, дающая наибольшее сферическое удовлетворение от вакуумных результатов такой практики на 1 джоуль в секунду.

K>>Уж во всяком случае автор кода лучше в нем разбирается, не будет ли в таком случае лучше, чтобы именно автор заботился о том, чтобы этот код было легче модифицировать и при этом сложнее совершить ошибки?

ГВ>Да, так будет лучше. Однако на момент разработки автор не всегда может даже предполагать, какие изменения с его кодом произойдут впоследствии. Образно выражаясь, вдруг кому-то из последователей придёт в голову прицепить плуг к подводной лодке, чтобы распахивать плантации морской капусты, а у неё стрингеры на это не рассчитаны? Так что, не разумно возлагать на автора ответственность за все возможные ошибки в последующих модификациях.

И снова приведение к абсурду с помощью знакомого уже приема Сферической Равновероятности Всего в Вакууме. Приведение к абсурду это, конечно, эффектно, но аргументом не является.
Некоторые предположения всегда можно сделать исходя из условий задачи. Понятно, что на присоединение плуга рассчитывать не стоит, тем более что усиление стрингеров просто так не осущетсвить, но вот возможность изменения модели баллистических ракет — рассчитывать нужно.
Только все это к делу не отностится. Мы говорим о том, стоит ли предпочесть более прочные стрингеры менее прочным, при условии что в ограничение по массе И ТЕ И ДРУГИЕ укладываются. Я думаю — да.

K>>если мы используем safe средства мы ничего не теряем. (Задача с использованием только таких средств решается)

ГВ>Мы теряем в читабельности кода и скорости исполнения. Это — как минимум. Поэтому следует заменить формулировку на: "...как правило, мы ничего не теряем".

Какой ужас. Я же все объяснил на пальцах — а понимания нет.
Если производительность недостаточна, то условия задачи НЕ выполнены.
Если производительность достататочна, то от того как будет меняться производительность выше оговоренного в условиях уровня мы ничего не выигрываем и не теряем.
Если все это не верно — допущена ошибка в формировании условий задачи. Ага?
Поэтому писать "как правило" нужно только в том случае, если мы ошиблись в условиях. Или если ничего не поняли.

Уменьшение читабельности — вопрос дискуссионный. Я бы скорее говорил об улучшении читабельности.

K>>если мы используем unsafe — мы теряем в надежности. Пусть даже только гипотетически.

ГВ>Ключ: гипотетически.

Вы углядели ключ не там. "Гипотетически" — в большинстве случаев максимальная степень уверенности, которую можно себе позволить. Поэтому, тому, кто отмахивается от всего гипотетического можно только посочувствовать.

K>>Не кажется ли Вам, что при таком условии следует доказывать не то, что, например код будет изменяться, а то, что он изменяться не будет?

ГВ>Нет. Этого доказать нельзя по определению и кроме того, само по себе условие содержит необоснованное допущение ("мы ничего не теряем" — теряем!). Можно только попытаться предсказать те или иные изменения с некоторой степенью достоверности.

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

K>>Да, мы, в каком-то смысле перестраховываемя, но ведь лучше перестраховаться, не так ли?

ГВ>Да, мы именно что перестраховываемся. То есть, вносим в программу функциональность, необходимость которой сомнительна. Лишняя перестраховка влечёт лишний объём кодирования, затрудняет отладку и т.п.

С ума сойти. Мы следуем критерию оптимальности указанному выше. Так что необходимость несомненна. Про затруднение отладки я вообще молчу. Конечно, порча памяти только облегчает отладку, а контроль буфера ее ужасно осложняет.

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

ГВ>Это просто метафоры. А как по-Вашему, ещё можно обозначить сущности, которые появятся только с некоторой вероятностью? Например — будущие изменения?

Вы хотите об этом поговорить? Я Вас шокирую. ВСЕ сущности появляются только с некоторой вероятностью.
Вот например вероятность появления таких сущностей как Вы или я неограниченно стремилась к нулю. И тем не менее мы с Вами существуем. Жизнь полна чудес.

K>>На самом деле, Дарнею вовсе не нужно доказывать, что что-то ОБЯЗАТЕЛЬНО случится.

ГВ>Разумеется. Это тоже недоказуемо. Однако, например, если на вход открытой библиотечной функции поступает простой const char*, то вполне разумно предположить, что он покажет невесть куда и невесть на что. Следовательно, в этом случае дополнительная защита на входе будет правомерной.

Не то слово. По вашему, делать нужно только то, за не деланье чего расстреливают (ну, или в наше доброе время просто увольняют)? А если не расстреляют, то делать нельзя ни в коем случае?

K>>Это Вам для опровержения его утверждения нужно доказать, что с кодом чего-то НИКОГДА не случиться.

ГВ>Нет, мой друг. Это доказать невозможно. Это даже утверждать-то нельзя. По отношению к своему примеру я утверждал несколько иное:
ГВ>- сам по себе приведённый пример не влечёт UB или GPF;
ГВ>- он компактен и легко модифицируется (всего пара строк).

Согласен. Утверждать это нельзя. Об этом я и говорю. Но Вы утверждаете. Такое Вы сможете утверждать только в том случае, если найдете волшебный способ сделать так, чтобы пара строк осталась парой навсегда. Если Вам удастся найти такой способ — вас сразу заберут живым в рай. В ту же секунду.

ГВ>Заметьте, я не пытался агитировать за применение такого подхода любой ценой.


И на том спасибо.

K>>Вместо этого приходится выслушивать истории про сферического программиста в вакууме, который обязательно посмотрит на одну строчку выше и решит все проблемы Вашего кода.

ГВ>От невнимательности программиста защиты не придумать.

Абсолютной нет. Но можно придумывать защиты все лучше и лучше. В плоть до таких, которые будут неограниченно приближаться к абсолюту. Защита от невнимательностей и улучшается. Вот например в большинстве современных языков тот милый фокус с точкой и запятой в фортрановском цикле и последующим пролетанием мимо Марса не повторить. И это достижение вовсе не отностится к самосовершенствованию программистов.

K>>В реальной жизни таких сферопрограммистов не сыщешь.

ГВ>Меня уже сферопрограммистом называют? Внесу в реестр необычных характеристик меня лично, спасибо.

Не называют. Вы самопровозглашенный сферопрограммист. Чувствуете нюанс?

K>>Лично я считаю, что всецело полагаться на благоразумие окружающих — как минимум неблагоразумно.

ГВ>Всецело и на всех — не знаю. А вот на коллег по цеху — почему бы и нет?

Это уже вопрос мировоззрения. Главное, чтобы вопрос мировоззрения не стал проблемой мировоззрения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[2]: Safe vs. unsafe - 2
От: klapaucius  
Дата: 02.06.06 12:00
Оценка: 32 (2) +1 :))) :))) :)
Здравствуйте, Cyberax, Вы писали:

C>klapaucius wrote:

>> На каком основании сделано предположение о том, что изменяющий строку
>> ПОСМОТРИТ на одну строчку вверх?
C>Элементарной компетентности. Можно сколько угодно делать безопасную
C>среду со всеми возможными проверками, но некомпетентный индус всегда
C>найдет способ сделать дырку.

И снова этот бессмертный аргумент. Ну да, можно разрезать ножницами изоляцию на электропроводе. Так что теперь, может вообще провода изоляцией не оборачивать? Дельное рацпредложение. Столько материалов можно сэкономить!

Вот есть амбар. В стену амбара забито 10 гвоздей. Пусть подразделение индусских пулеметчиков стреляет по амбару каждый день с девяти до шести. Рано или поздно они попадут в шляпку гвоздя. Но если гвоздей будет 100 это случится гораздо раньше.

Мои иллюстрации ясны?

C>За примерами — на thedailywtf.


Я вот сейчас подумал, чем отличается ужасный код написанный индусом, от ужасного кода написанного кулхацкером и ужасного кода написанного профессионалом.

Код индуса очевидно ужасен для любого опытного программиста. Проблемы в коде очевидны.

Код кулхацкера ужасен, но не для всех. Найдется много людей, которые посчитают этот код очень милым.

Код профессионала ужасен неочевидным образом. Вопрос его ужасности или неужасности отличный повод для дискуссий других профессионалов. Проблемы также неочевидны, и проявления этих проблем носят полумистический характер. Поэтому их последствия особенно ужасны.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Тяжело искать кошку, когда её нет
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.06.06 21:11
Оценка: -2
Здравствуйте, klapaucius, Вы писали:

Заранее sorry модераторам за оверквотинг.

ГВ>>Нельзя доказать негативно сформулированный тезис.

K>О чем я и говорю.

Но упорно требуете от меня доказательств.

ГВ>>Я сразу сформулирую свой основной тезис, чтобы было понятнее.

ГВ>>
Любое средство защиты от чего-то служит для защиты от чего-то определённого. Соответственно, внедряя защиту какого-либо характера мы предотвращаем ту или иную вполне определённую группу ошибок. Однако, следует учесть, что множество только внутренних ошибок ограничено едва ли не множеством допустимых комбинаций идентификаторов. Следовательно, никакой код нельзя защитить ото всех возможных ошибок. Следовательно, для каждой конкретной задачи нужно выбирать оптимальную модель защиты от ошибок.

ГВ>>

ГВ>>Ну а теперь — поехали дальше.

K>Дальше ехать нет никакой возможности, потому, что тезис этот понятности не добавляет и вот почему:

K>1) Вы в нем только и делаете, что определяете неопределенность через неопределенность. Понятно, что Вы устанавливаете соответствие между классом средств защиты и классом проблем, для защиты от которых они предназначены, но такое соответствие тривиально. Поймите, сказать что нужно выбирать оптимальную модель — ничего не сказать, ведь КРИТЕРИЙ ОПТИМАЛЬНОСТИ Вы не указали.

Правильно. Я и не собирался указывать никаких конкретных критериев оптимальности защиты. Ибо они зависят от многих факторов, под влиянием которых пишется та или иная программа. В общем случае можно сказать только то, что выбираемые критерии оценки оптимальности зависят от конкретных условий. То есть, не пределимы в столь любимом многими "общем случае".

K>Вот у Дарнея критерий четко сформулирован: максимизация надежности при выполнении условий задачи, даже в том случае, если максимизация надежности в условиях задачи не оговорена.


Да, у Дарнея сформулирован критерий. Только это критерий не оптимальности, а критерий оценки самого решения, применяемый безотносительно оценки оптимальности. Практически — нравственный императив.

Может быть, я чего-то очень важного не понимаю, но как-то привык, что оптимальность подразумевает некие расчёты над какими-то цифирями, а отнюдь не императивы: "делай только этак!" В крайнем случае можно ограничиться трезвым суждением: "надо ли это здесь и сейчас?"

K>А у Вас что? Ясной формулировки я не увидел. А при отсутствии ясно выраженного критерия Ваш тезис тезису Дарнея и не противоречит.


Отнюдь. Он отвергает императив "safe надо всегда, если нет недопустимого оверхеда по производительности". Потому что в частном случае может оказаться, что snprintf избыточен, хотя накладными расходами в run-time можно и пренебречь.

K>2) Другой недостаток заключается в том, что Вы утверждаете

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

делая после этого какие-то далеко идущие выводы. Понятно, что множество ошибок велико, однако дело в том, что ошибки эти не равновероятны. Я выдвигаю такую гипотезу: если провести статистический анализ ошибок, совершаемых программистами, то в большинстве случаев будут совершаться ошибки из некоторого ограниченного подмножества множества всех возможных ошибок.


Поддерживаю гипотезу.

K>Вот аналогия, которая, разумеется, ничего не доказывает, зато неплохо иллюстрирует:

K>Множество возможных смертей очень велико, онако из этого вовсе не следует, что не нужно уделять много сил заботе о здоровье сердца, на основании того, что защищать голову от падения метеоритов это очевидный для всех идиотизм. Ведь от сердечно-сосудистых заболеваний умерает, допустим 50% людей, а от попаданий метеоритов один человек за всю историю. Это просто логически некорректно.

K>Защитники safe средств считают, по видимому, что ошибки связанные с unsafe средствами как раз и относятся к подмножеству ошибок, совершаемых гораздо чаще прочих.


Похоже, что так оно и есть.

K>>>На каком основании сделано предположение о том, что изменяющий строку ПОСМОТРИТ на одну строчку вверх?

ГВ>>С равным успехом можно перепутать последовательность идентификаторов в таком выражении:

ГВ>>
ГВ>>String s = tagged(tag1, v1) + tagged(tag2, v2);
ГВ>>


K>Ну вот, опять! Почему же с равным? Где данные о том, что вероятность такой ошибки приближенна равна вероятности ошибки с изменением формата строки?


Бессмысленно сравнивать одну невнимательность и другую невнимательноть. Если мы допускаем возможность того, что программист не посмотрит на одну (прописью: одну!) строчку кода вверх, то есть полагаем его весьма невнимательным человеком, то продолжая такое скользкое рассуждение, мы можем предположить, что программист не посмотрит и на две строчки вверх и перепутает последовательность идентификаторов.

ГВ>>Так что, внимательность и понимание сути правок необходима программисту по-любому.

K>Несомненно. Однако, внимательность человека очень ограничена. Поэтому и необходимы средства автоматического контроля и средства повышения абстракции. Все для уменьшения нагрузки на внимательность.

Да, внимание тоже не безгранично. Но говорить, что глянуть на строчку вверх — перегрузка внимания, по-моему, перебор.

ГВ>>Другое дело, что в силу определённых, зачастую привитых социумом, стереотипов ему может быть неприятно заботиться о тех или иных аспектах программы, но это уж вопрос о психоустойчивости...

K>Боюсь, что дело тут не в стереотипах. Разные аспекты объективно неравнозначны. Я не могу доказать, что это так, но могу сказать, что ВЕРОЯТНОСТЬ того, что они равнозначны очень низка. Если у Вас другие данные — было бы интересно их увидеть. Однако, даже если аспекты СУБЪЕКТИВНО неравнозначны — это ничего по существу не меняет. Я считаю, что лучше подгонять инструмент под человека, а не человека под инструмент.

Согласен. И как раз этому взгляду противоречит тезис о "всегда выбирайте safe, если не будет runtime-перегрузки".

K>>>По сути — это делегирование ответственности тому, кто будет модифицировать код в будущем.

ГВ>>Она в любом случае делегируется именно ему.
K>В любом случае делегируется ЧАСТЬ ответственности. Не стоит устремлять эту часть к целому.

То есть, если автор программы уволился, то он по-прежнему отвечает за неё, даже если её код передан сопровождающим программистам? Что-то не так в датском королевстве.

K>>>Вы считаете, что это хорошая практика?

ГВ>>Что такое "хорошая практика"?

K>Хорошая сферическая практика в вакууме — это практика, дающая наибольшее сферическое удовлетворение от вакуумных результатов такой практики на 1 джоуль в секунду.


Ну, понятно. За сим даже не обращаю внимания на апелляцию к личности.

K>>>Уж во всяком случае автор кода лучше в нем разбирается, не будет ли в таком случае лучше, чтобы именно автор заботился о том, чтобы этот код было легче модифицировать и при этом сложнее совершить ошибки?

ГВ>>Да, так будет лучше. Однако на момент разработки автор не всегда может даже предполагать, какие изменения с его кодом произойдут впоследствии. Образно выражаясь, вдруг кому-то из последователей придёт в голову прицепить плуг к подводной лодке, чтобы распахивать плантации морской капусты, а у неё стрингеры на это не рассчитаны? Так что, не разумно возлагать на автора ответственность за все возможные ошибки в последующих модификациях.

K>И снова приведение к абсурду с помощью знакомого уже приема Сферической Равновероятности Всего в Вакууме. Приведение к абсурду это, конечно, эффектно, но аргументом не является.


А что? Является аргументом призыв возложить всю ответственность на автора? Это звучит как минимум, странно. Если сопровождающие программисты прохлопали ошибку в программе, то при чём тут автор? Да, если это он её изначально допустил, то ему — персональный ай-яй-яй, но прямая ответственность за её выкусывание уже ложится на тех, кто занимается сопровождением. Не устраивает? Пусть переписывают.

Просто так уж повелось, что большинство всё-таки хочет не просто оттарабанить свои восемь часов, а ещё и сделать что-то хорошее, что-то такое, от чего они получат некоторое моральное удовлетворение. А это зачастую невозможно без взятия на себя некоторой существенной доли ответственности. Потому, я уверен, что тезис об ответственности автора за всё пройдёт "на ура". Скажу больше, даже я с ним в чём-то согласен.

K>Некоторые предположения всегда можно сделать исходя из условий задачи. Понятно, что на присоединение плуга рассчитывать не стоит, тем более что усиление стрингеров просто так не осущетсвить, но вот возможность изменения модели баллистических ракет — рассчитывать нужно.


Совершенно верно. Некоторые предположения сделать можно. Однако, приведённый мной пример содержит решение очень маленькой задачи. Из таких примеров можно сделать сколь угодно чудовищные индукции. Однако, вся беда в том, что все эти индукции — химеры. То есть, следствие попыток представить, что нечто появится там, где его нет. И самое интересное, что и условий-то для подобных представлений нет.

Я бы охотно согласился с доводами стронников safe, если бы была возможность предположить существование соответствующих угроз. Но оснований-то для таких предположений — нет!

K>Только все это к делу не отностится. Мы говорим о том, стоит ли предпочесть более прочные стрингеры менее прочным, при условии что в ограничение по массе И ТЕ И ДРУГИЕ укладываются. Я думаю — да.


Зависит от. Например, предпочтя менее (но достаточно!) прочные стрингеры, можно выиграть в допустимой массе электроники.

K>>>если мы используем safe средства мы ничего не теряем. (Задача с использованием только таких средств решается)

ГВ>>Мы теряем в читабельности кода и скорости исполнения. Это — как минимум. Поэтому следует заменить формулировку на: "...как правило, мы ничего не теряем".

K>Какой ужас. Я же все объяснил на пальцах — а понимания нет.

K>Если производительность недостаточна, то условия задачи НЕ выполнены.
K>Если производительность достататочна, то от того как будет меняться производительность выше оговоренного в условиях уровня мы ничего не выигрываем и не теряем.
K>Если все это не верно — допущена ошибка в формировании условий задачи. Ага?
K>Поэтому писать "как правило" нужно только в том случае, если мы ошиблись в условиях. Или если ничего не поняли.

Я потому и пишу "как правило", что согласен, что зачастую особых требований к производительности не предъявляется. Во всяком случае, влияние дополнительного обсчёта длины буфера не заметно даже в мелкосоп. Суть не в этом.

Суть в том, что я привёл один простой и конкретный пример, где выход за пределы буфера невозможен на распространённых архитектурах в принципе. То есть — его нет вообще, хоть что хочешь делай. И хакерская угроза через него не пройдёт. Понимаете? Может быть, это для кого странно прозвучит, но я не пытался (и не пытаюсь) обобщать это решение в какую бы то ни было сторону. Я не пытаюсь назвать его "хорошей практикой" или призвать "делай как я!". Не пытаюсь сказать, что "snprintf — must die, sprintf — ruleZZZ". Я этого не пытаюсь и не пытался сделать. Я также сознательно не озвучивал никаких предположений относительно жизненного цикла этого куска кода и возможных модификаций. Я только лишь проиллюстрировал простую мысль: не всегда стоит придерживаться распространённых, даже "хороших" практик. То есть, безусловно, можно сделать даже свою систему форматирования, но только тогда, когда это оправдано. В даном случае, все такие оправдания придуманы сторонниками safe. Бесспорно, они все почерпнуты из реалий профессиональной деятельности. Но в данном конкретном случае все такие предположения до единого — химеричны, поскольку не имеют достаточных на то оснований, ибо дать их мог только я (в данном конкретном случае), а я этого делать не стал. Таким образом, все основания подведены теми же сторонниками safe, то есть, попросту придуманы, взяты "от Балды". Что, собственно, происходит почти всегда, если руководствоваться абстрактными принципами, а не здравым смыслом.

K>Уменьшение читабельности — вопрос дискуссионный. Я бы скорее говорил об улучшении читабельности.


Появляются дополнительные, совершенно бесполезные символы и вычисления. Вот и ухудшение читабельности. Лишняя цепочка, которую нужно проконтролировать.

K>>>если мы используем unsafe — мы теряем в надежности. Пусть даже только гипотетически.

ГВ>>Ключ: гипотетически.
K>Вы углядели ключ не там. "Гипотетически" — в большинстве случаев максимальная степень уверенности, которую можно себе позволить. Поэтому, тому, кто отмахивается от всего гипотетического можно только посочувствовать.

А... То есть, это метафора такая.

Но это ничего не меняет. Гипотетическая потеря надёжности от гипотетических же исправлений позволяет нам оценить такое рассуждение, как гипотетичное в квадрате. То есть — всё ближе к сфероконю...

K>>>Не кажется ли Вам, что при таком условии следует доказывать не то, что, например код будет изменяться, а то, что он изменяться не будет?

ГВ>>Нет. Этого доказать нельзя по определению и кроме того, само по себе условие содержит необоснованное допущение ("мы ничего не теряем" — теряем!). Можно только попытаться предсказать те или иные изменения с некоторой степенью достоверности.
K>Так я и говорю, что слабость Вашего утверждения в том, что его или нельзя доказать, или доказывать в нем нечего. Что касается потерь — см. выше.

В десятку! В том-то и дело, что доказывать нужно именно эти ваши всегда-нужности. И в особенности — их "всегдашность".

K>>>Да, мы, в каком-то смысле перестраховываемя, но ведь лучше перестраховаться, не так ли?

ГВ>>Да, мы именно что перестраховываемся. То есть, вносим в программу функциональность, необходимость которой сомнительна. Лишняя перестраховка влечёт лишний объём кодирования, затрудняет отладку и т.п.

K>С ума сойти. Мы следуем критерию оптимальности указанному выше. Так что необходимость несомненна.


Ага. То есть следуем не конкретным требованим и условиям текущего контекста, а абстрактным тезисам: "надо всегда, надо везде". Мило, мило.

K>Про затруднение отладки я вообще молчу. Конечно, порча памяти только облегчает отладку, а контроль буфера ее ужасно осложняет.


Не знаю насчёт ужасного усложнения отладки, но то, что дополнительные страховки требут дополнительной отладки, ИМХО, несомненно.

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

ГВ>>Это просто метафоры. А как по-Вашему, ещё можно обозначить сущности, которые появятся только с некоторой вероятностью? Например — будущие изменения?
K>Вы хотите об этом поговорить? Я Вас шокирую. ВСЕ сущности появляются только с некоторой вероятностью.
K>Вот например вероятность появления таких сущностей как Вы или я неограниченно стремилась к нулю. И тем не менее мы с Вами существуем. Жизнь полна чудес.

А... у... Ага, ага...

K>>>На самом деле, Дарнею вовсе не нужно доказывать, что что-то ОБЯЗАТЕЛЬНО случится.

ГВ>>Разумеется. Это тоже недоказуемо. Однако, например, если на вход открытой библиотечной функции поступает простой const char*, то вполне разумно предположить, что он покажет невесть куда и невесть на что. Следовательно, в этом случае дополнительная защита на входе будет правомерной.
K>Не то слово. По вашему, делать нужно только то, за не деланье чего расстреливают (ну, или в наше доброе время просто увольняют)? А если не расстреляют, то делать нельзя ни в коем случае?

Не надо придавать моим высказываниям категоричность, которой там нет. Я не пытаюсь выставить sprintf в качестве императива. Речь о том, что утверждение "всегда надо выбирать safe, если достаточна производительность" — ошибочно в своей категоричности.

K>>>Это Вам для опровержения его утверждения нужно доказать, что с кодом чего-то НИКОГДА не случиться.

ГВ>>Нет, мой друг. Это доказать невозможно. Это даже утверждать-то нельзя. По отношению к своему примеру я утверждал несколько иное:
ГВ>>- сам по себе приведённый пример не влечёт UB или GPF;
ГВ>>- он компактен и легко модифицируется (всего пара строк).
K>Согласен. Утверждать это нельзя. Об этом я и говорю. Но Вы утверждаете. Такое Вы сможете утверждать только в том случае, если найдете волшебный способ сделать так, чтобы пара строк осталась парой навсегда. Если Вам удастся найти такой способ — вас сразу заберут живым в рай. В ту же секунду.

Это ещё почему? Я как раз вполне допускаю, что при первой же модификации и при необходимости эта пара строк с лёгкостью чрезвычайной будет заменена на другую, априори неизвестного содержания.

ГВ>>Заметьте, я не пытался агитировать за применение такого подхода любой ценой.

K>И на том спасибо.

Пожалуйста.

K>>>Вместо этого приходится выслушивать истории про сферического программиста в вакууме, который обязательно посмотрит на одну строчку выше и решит все проблемы Вашего кода.

ГВ>>От невнимательности программиста защиты не придумать.

K>Абсолютной нет. Но можно придумывать защиты все лучше и лучше. В плоть до таких, которые будут неограниченно приближаться к абсолюту. Защита от невнимательностей и улучшается. Вот например в большинстве современных языков тот милый фокус с точкой и запятой в фортрановском цикле и последующим пролетанием мимо Марса не повторить. И это достижение вовсе не отностится к самосовершенствованию программистов.


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

K>>>В реальной жизни таких сферопрограммистов не сыщешь.

ГВ>>Меня уже сферопрограммистом называют? Внесу в реестр необычных характеристик меня лично, спасибо.
K>Не называют. Вы самопровозглашенный сферопрограммист. Чувствуете нюанс?

Хех. У меня код, подобный приведённому не вызвает проблем. Ни в моём коде, ни в том коде, с которым я сталкивался. Вы утверждаете, что в реальной жизни таких программистов не сыщешь. Вывод?
<< Под музыку: Аквариум — Пабло >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Дополнение
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.06.06 21:19
Оценка:
Не совсем верно выразился:

ГВ>... или призвать "делай как я!".


Следует читать как: "...или призвать "Всегда и везде делай, как я!" "

Всё зависит от конкретных условий.
<< Под музыку: Аквариум — Пабло >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Safe vs. unsafe - 2
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.06.06 21:22
Оценка: -2
Здравствуйте, klapaucius, Вы писали:

C>>Элементарной компетентности. Можно сколько угодно делать безопасную

C>>среду со всеми возможными проверками, но некомпетентный индус всегда
C>>найдет способ сделать дырку.

K>И снова этот бессмертный аргумент. Ну да, можно разрезать ножницами изоляцию на электропроводе. Так что теперь, может вообще провода изоляцией не оборачивать? Дельное рацпредложение. Столько материалов можно сэкономить!


Не надо обобщать без достаточных на то оснований, только и всего.
<< Под музыку: Аквариум — Пабло >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: ...и анекдот напоследок
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:33
Оценка:
Здравствуйте, klapaucius, Вы писали:

Просто тихо снимаю шляпу перед автором этих и этих
Автор: klapaucius
Дата: 02.06.06
слов.

Всегда завидовал людям которые могут так кратко и доходчиво донести свои мысли. К сожалению у меня это не всегда получается.
... << RSDN@Home 1.2.0 alpha rev. 637>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Safe vs. unsafe - 2
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:58
Оценка:
Здравствуйте, klapaucius, Вы писали:

K>Несомненно. Однако, внимательность человека очень ограничена. Поэтому и необходимы средства автоматического контроля и средства повышения абстракции. Все для уменьшения нагрузки на внимательность.


Сори, это давний спор на наших просторах и на подобные аргументы очень часто следует контраргумент вроде: "безопасные языки придумны для индусов", "настоящий проффесионал не делает глупых ошибок и контролирует ситуацию".

По мне так это бравада и не понимание того, что силы можно тратить на действительно нужные задачи, а не на параноидальный контроль окружающего. Но все же хотелось бы выслушать твои аргументы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да, что уж там? Полный слив был еще пару писем назад. :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 01:09
Оценка: -2
... << RSDN@Home 1.2.0 alpha rev. 637>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Не сдержался, извиняюсь.
От: c-smile Канада http://terrainformatica.com
Дата: 03.06.06 02:28
Оценка: 53 (6) +2 -2
Здравствуйте, klapaucius, Вы писали:

K>Если мы не можем решить задачу используя ТОЛЬКО safe средства — мы используем unsafe;

K>если же мы МОЖЕМ решить задачу используя ТОЛЬКО safe — то только такие средства и следует использовать.

K>Все просто, не так ли?


1) не просто, 2) не так.

(Про жену и statements типа ТОЛЬКО, ВСЕГДА, НИКОГДА я уже писал неоднократно — повторяться не буду)

Средства должны быть адекватны решаемой задаче. Вот собственно и все. В такой постановке
любые "ТОЛЬКО" уже просто преступная ошибка дизайна.

И опять же: не бывает safe средств в принципе.
Бывают как бы safe средства которые создают ложное ощущение безопасности.

Возвращаясь к теме разговора: strcpy vs. strncpy (так по-моему звучало).
Есть ситуация когда strncpy не ставит 0 в конце. Дальше я думаю
рассказывать не надо чего может быть.

По поводу управляемых сред: почему-то считается что GPF это страшно
а утекающая память (в GC системах), вечные циклы или дедлоки это не страшно.

GPF если честно это наименьшая проблема из встречающихся.
Все остальные головные боли не зависят от safe / не safe и они общие для всего програмизма.

Теорема Райса (Rice's theorem) (следствие halting problem) гласит что только тривиальные свойства програм алгоритмически доказуемы. Включая их безопасность. Все. Трындец. Можно успокоится и сообщить прожект манагерам что на упаковке может быть написано все что угодно про safety — рояли это не играет... .
Думаешь?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.06.06 02:45
Оценка: :)))
Да ладно тебе!

В театре абсурда слив невозможен.
<< Под музыку: Аквариум — Капитан Белый Снег >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: ...и анекдот напоследок
От: Cyberax Марс  
Дата: 03.06.06 08:46
Оценка: 1 (1) +5 -3 :)
klapaucius wrote:
> C>Элементарной компетентности. Можно сколько угодно делать безопасную
> C>среду со всеми возможными проверками, но некомпетентный индус всегда
> C>найдет способ сделать дырку.
> И снова этот бессмертный аргумент. Ну да, можно разрезать ножницами
> изоляцию на электропроводе. Так что теперь, может вообще провода
> изоляцией не оборачивать? Дельное рацпредложение. Столько материалов
> можно сэкономить!
Хорошая аналогия. Найди, пожалуйста, изоляцию на высоковольтных проводах
ЛЭП.

.NET тут предлагает обернуть каждый провод (да, в том числе и тот, в
котором 500КВ) в десять сантиметров керамики — и их можно класть прямо
на асфальт, даже не закапывая.

> Вот есть амбар. В стену амбара забито 10 гвоздей. Пусть подразделение

> индусских пулеметчиков стреляет по амбару каждый день с девяти до шести.
> Рано или поздно они попадут в шляпку гвоздя. Но если гвоздей будет 100
> это случится гораздо раньше.
> Мои иллюстрации ясны?
Да. Качество ПО мало зависит от языка разработки. Ну напишут индусы
крутую IDE (участвовал в разработке такой, до сих пор с ужасом
вспоминаю) — она ведь даже может исключения не будет печать, но ведь и
пользоваться ей будет нельзя.

> C>За примерами — на thedailywtf.

> Я вот сейчас подумал, чем отличается ужасный код написанный индусом, от
> ужасного кода написанного кулхацкером и ужасного кода написанного
> профессионалом.
> Код индуса очевидно ужасен для любого опытного программиста. Проблемы в
> коде очевидны.
> Код кулхацкера ужасен, но не для всех. Найдется много людей, которые
> посчитают этот код очень милым.
Конечно. Точно так же книга по высшей математике покажется ужасом
школьнику. Но повод ли это выкидывать всю вышку, чтобы каждый школьник
мог после десятого (или даже восьмого класса!) сразу вливаться в команду
по разработке алгоритмов сжатия изображений?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[2]: Не сдержался, извиняюсь.
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.06.06 13:07
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Есть ситуация когда strncpy не ставит 0 в конце.


Угу, точно-точно. Как раз в ситуации нехватки буфера. Совсем правильное использование strncpy подразумевает вот такую конструкцию:

strncpy(dest, src, n);
dest[n-1] = 0;
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: ...и анекдот напоследок
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:25
Оценка: 1 (1) +2
Здравствуйте, Cyberax, Вы писали:

C>Хорошая аналогия. Найди, пожалуйста, изоляцию на высоковольтных проводах

C>ЛЭП.

Изоляцией в данном случае является 20 метров воздуха. Без особых услий фиг дотянешся... В общем, защита один фиг предусмотрена.

Если же кабель проложен по земле или под землей, то изоляции на нем хватает.

C>.NET тут предлагает обернуть каждый провод (да, в том числе и тот, в

C>котором 500КВ) в десять сантиметров керамики — и их можно класть прямо
C>на асфальт, даже не закапывая.

10 сантиметров керамики — это полд больного воображения. Защиты столько сколько нужно, чтобы уберечь от повреждения тех кто намеренно не пытается ее сломать. Плюс не дать ее сломать тем у кого на это нет прав. Но тут уже анлогии надо искать в других местах. Да и 10 см. кирамики отнюдь не лишние если речь идет о киловольтах.

Заметь, автор этой аналогии ничего не доказывал ею. Он иллюстрировал ею ситуацию. Ты же пытаешся что-то доказать. При этом используешь высосанные из пальца вещи вроде 10 см. керамики.

C>Да. Качество ПО мало зависит от языка разработки.


Теория и практика показывает ровно обратное.

C> Ну напишут индусы

C>крутую IDE (участвовал в разработке такой, до сих пор с ужасом
C>вспоминаю) — она ведь даже может исключения не будет печать, но ведь и
C>пользоваться ей будет нельзя.

По-моему, объяснение klapaucius было настолько доходчивым и обоснованным, то твои попытки проигнорировать его и снова гнуть свою, в дрыз разнесенную, линию просто не разумно. Надо уметь менять позицию если собственная несостоятельна.

>> C>За примерами — на thedailywtf.

>> Я вот сейчас подумал, чем отличается ужасный код написанный индусом, от
>> ужасного кода написанного кулхацкером и ужасного кода написанного
>> профессионалом.
>> Код индуса очевидно ужасен для любого опытного программиста. Проблемы в
>> коде очевидны.
>> Код кулхацкера ужасен, но не для всех. Найдется много людей, которые
>> посчитают этот код очень милым.
C>Конечно. Точно так же книга по высшей математике покажется ужасом
C>школьнику. Но повод ли это выкидывать всю вышку, чтобы каждый школьник
C>мог после десятого (или даже восьмого класса!) сразу вливаться в команду
C>по разработке алгоритмов сжатия изображений?

Нда, случай клинический — гляжу в книку вижу фигу — или — угодал все буквы не смог прочесть слово. Тут не говорится о том, что сложный код или код написанный проффесионалом — это зло. Здесь говорится, что касяк допущенный проффесионалом куда более опасен нежели косяк допущенный индусом, и обосновывается почему это так. И любой разумный человек должен сделать вывод, что чем проффесиональнее программист, тем больше ему нужно уделять внимания написанию корректного, безопасного кода не вызвающего проблем при изменении его другими.
... << RSDN@Home 1.2.0 alpha rev. 637>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Не сдержался, извиняюсь.
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 03.06.06 13:26
Оценка: 4 (1)
c-smile,

CS>Теорема Райса (Rice's theorem) (следствие halting problem) гласит что только тривиальные свойства програм алгоритмически доказуемы. Включая их безопасность. Все. Трындец. Можно успокоится и сообщить прожект манагерам что на упаковке может быть написано все что угодно про safety — рояли это не играет... .


Поправочка, не сочти буквоедом.

Фундаментальность теоремы Райса неоспорима, однако практика не столь богата и наши железяки — жалкий частный случай машины Тьюринга.

А общее утверждение в каком-то частном случае может поиметь совсем другую окраску.

Применительно к halting problem практически мы сплошь и рядом "решаем" эту задачу, когда по ctrl-alt-del снимаем зависший процесс, или слишком долго не откликающийся на пинки поток. Все сервера сплошь и рядом "решают" halting problem отпинывая клиента по таймауту.

Также есть theorem prover-ы, которые позволяют доказать нетривиальные свойства программ, как например отсутствие обращения по нулевому указателю. Опять же теореме Райса это не противоречит, поскольку всегда возможна ситуация, когда этот бедняга не может доказать, что obj не равен нулю и выдаст "наверное obj может быть равен нулю, но сильно ногами не пинайте, я немножко не знаю ???". Но и здесь задача "решается" практически путём вставки дополнительных assumption-ов и тыкания носом teorem prover-а в них.
http://files.rsdn.org/10144/thinker.gif quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[3]: Не сдержался, извиняюсь.
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 15:37
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Также есть theorem prover-ы, которые позволяют доказать нетривиальные свойства программ, как например отсутствие обращения по нулевому указателю. Опять же теореме Райса это не противоречит, поскольку всегда возможна ситуация, когда этот бедняга не может доказать, что obj не равен нулю и выдаст "наверное obj может быть равен нулю, но сильно ногами не пинайте, я немножко не знаю ???". Но и здесь задача "решается" практически путём вставки дополнительных assumption-ов и тыкания носом teorem prover-а в них.


Скажу больше. Это уже входит в нашу жизнь. В MS Research уже работают над Spec# в состав которого входит Boogie который позволяет проверять на корректность MSIL-код размеченного специальным образгом. Насколько мне извесно в Немерле есть планы испльзовать этот фрэймворк.
... << RSDN@Home 1.2.0 alpha rev. 637>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Весело гармонь поёт!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.06.06 15:44
Оценка: +3 -4
Здравствуйте, VladD2, Вы писали:

C>>Да. Качество ПО мало зависит от языка разработки.

VD>Теория и практика показывает ровно обратное.

Да????? Почему же тогда сугубо надёжный Янус умудрялся впадать в мёртвое зацикливание (excpetion — продолжить — exception ...) при вводе неправильного тега в строчку подписи? Почему не предотвращал многопоточные транзакции релизом ранее? Ведь это же так просто сделать!

VD>По-моему, объяснение klapaucius было настолько доходчивым и обоснованным, то твои попытки проигнорировать его и снова гнуть свою, в дрыз разнесенную, линию просто не разумно. Надо уметь менять позицию если собственная несостоятельна.


Лихо. Значит, дело обстоит так. Safe-тусовщики ставят шоу, используя вот такие методы:

а) апеллируют к инопланетным кулхацкерам (гротеск изящен, но обычно неуместен);
б) выдумывают всё новые и новые "аргументы" (именно выдумывают, и в данном случае я предметно объяснил
Автор: Геннадий Васильев
Дата: 03.06.06
, почему это так);
г) выступают с околонаучно оформленным софизмом, суть которого выглядит так: "негативный тезис нельзя доказать, но ты его должен доказать" (жаль, не многие слышали, как я ржал из-под стула);
в) наконец, переходят к открытым уговорам: "ну твоя же позиция разнесена!"

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

Э... Так, и, позволю себе спросить, чья тут позиция-то разнесена?

VD>И любой разумный человек должен сделать вывод, что чем проффесиональнее программист, тем больше ему нужно уделять внимания написанию корректного, безопасного кода не вызвающего проблем при изменении его другими.


Вывод здесь можно сделать и другой, а именно: код, написанный одними профессионалами должны править другие профессионалы. Именно поэтому главные конструкторы подводных лодок сменяются другими опытными конструкторами, а не вчерашними выпускниками.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: ...и анекдот напоследок
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.06.06 15:48
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>Изоляцией в данном случае является 20 метров воздуха. Без особых услий фиг дотянешся... В общем, защита один фиг предусмотрена.


А у некоторых изоляцией от ошибок служит 10-15 лет опыта программирования. Так что, защита предусмотрена by design.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.