> А вы, продолжайте юлить и юродствовать - мне ваши и им подобные
> опусы одно удовольствие разбирать.Ну, судя по тому, что вы не поленились написать ответ на один из этих "опусов" длиной аж в два экрана, вам их действительно удовольствие разбирать.
> Не пишут безопасные системы, а голословно заявляют о безопасности систем.
Пока что именно вы голословно заявляете о том, что якобы существуют какие-то более безопасные системы, написанные на каких-то более безопасных языках.
>> Еще раз говорю: безопасность всегда достигается за счет вашего контроля над системой.
> Ещё раз опровергаю: язык, предоставляющий средства безопасного программирования, априори
> не ограничивает пресловутый "контроль над системой". Я даже больше скажу: он
> его усиливает, позволяя писать безопасный код. На том же Си ещё
> не написано ни одной безопасной сложной системы, работающей с данными на
> уровне абстракций самого Си.
Голословное утверждение. Давайте конкретно: какие ОС промышленного уровня, написанные не на Си, оказались более безопасными и по каким критериям?
> И сейчас вы на примере трёх (!) типов строк в Аде будете
> мне рассказывать об увеличении количества типов? Во-первых, обосновать большую сложность
> работы со строками в Аде по сравнению с Си вы не
> сможете - ни умозрительно, ни на примерах. Дерзайте!
Имелась ввиду не сложность работы со строками _вообще_, а сложность реализации этой работы применительно к конкретным областям. В частности мы говорили о "безопасных" ОС. Так вот работать со строками в Си не удобно, но их реализация крайне проста и наиболее близка к машинному представлению. В результате она оказывается более эффективной, чем реализация строк в Аде, которая а) скрыта от программиста, б) варьируется в зависимости от типа и в) варьируется в зависимости от компилятора.
> Во-вторых, сколько специальных целочисленных типов в Си? Мало ли уязвимостей было (есть
> и будет) из-за целочисленных переполнений при неявных преобразованиях результата? А сколько
> функций безопасной работы со строками (str*, strn*, strl*), не способных, к
> тому же, окончательно решить проблему их небезопасной обработки? А сколько внутренних
> API для работы со строками реализовано в рамках проектов с повышенными
> требованиями к безопасности (софт Бернштейна, vsftpd, Dovecot)?
Но люди продолжают и продолжают на этом писать! Неужели вы считаете, что все 100% этих программистов в течение многих лет продолжают заниматься самообманом? :) Так можно и до теорий заговоров договориться...
> Как просто, оказывается, в Си работать со строками - ну полный контроль!
> И как сложно в Аде - три типа, и никакого контроля.
> Ещё расскажите мне про "лишний код" - вот тут я действительно,
> буквально посмеюсь.
Да, лишний код, и это не смешно. Если я работаю с динамическими строками сразу возникают проблемы распределения памяти и сборки мусора, которые неизбежно порождают лишний код. Если в приложении этот код без проблем выполняет ран-тайм библиотека, то в ядре ОС управление этим кодом может стать головной болью программиста и, в конечном счете, привести к ослаблению безопасности.
>> типов строк (Bounded, Fixed, Unbounded...). В результате я должен сначала не
>> ошибиться, выбирая какой тип строк использовать в каждой конкретной ситуации, а
> Ах, ох. И какова же цена ошибки? Каковы типичные ошибки? Как часто
> возникают? Насколько легко идентифицировать и исправить? Давайте сравнивать с Си.
Давайте. Давайте для начала приведем примеры ОС, которые могут делать хоть что-нибудь, кроме как "быть безопасными", а потом посмотрим насколько не соответствуют этому призрачному идеалу реально существующие ОС.
>> потом гадать, что из этого получится в ядре написанной мной ОС,
> В Си вы тоже гадаете вместо того, чтобы спецификацию на язык почитать?
В Си спецификация очень проста - массив символов, заканчивающийся нулем. Все операции со строками самоочевидны. А вот что творит со строками Ада - я не знаю. Да мне и не надо знать, если я пишу приложение. Но если это встроенная система, работающая на голом железе, то мне совсем не безразлично в какой момент компилятор захочет вызывать менеджер памяти или сборщик мусора.
> Во истину каждый кулик своё болото хвалит. Вы одно забыли упомянуть -
> в Си, в отличие от C++, приемлемой альтернативы ASCIZ просто нет.
> ;)
Если бы в С++ была приемлемая реализация строк, мы бы не наблюдали того зоопарка строковых библиотек, который поставляет со своими продуктами каждый разработчик компиляторов.
> К слову, ядра ОС сейчас собираются отдельными версиями компиляторов - каждый требует
> подгонки по различным причинам. И структуры выравниваются в зависимости от архитектуры,
> и endianess слов учитывается. Зато контроль какой - каждая мелочь контролируется!
Это какие ядра собираются разными версиями компиляторов? Примеры, пожалуйста.
>> А забота о безопасности _в_принципе_ ложится на программиста. Если вы считаете, что
> Здесь вы передёрнули смысл словосочетания "безопасность кода" и невинно перевели разговор
> с обсуждения отдельного аспекта обеспечения безопасности (безопасного кода в смысле типобезопастности)
> на безопасность вообще. 4 за находчивость, 2 за предпочтение дешевой полемики
> разговору по существу.
Слабость вашей позиции в том, что вы воспринимаете безопасность кода как единственный критерий эффективности системы. Причем даже не безопасность вообще, а почему-то именно типобезопасность! В этом есть некий солипсизм. Реальность же такова, что абсолютно безопасных систем не бывает, более того, в них нет необходимости! Сюрприз? Обычно требуется некий компромисс между определенным уровнем безопасности, скорости, потреблением ресурсов и т.п. Как показывает практика, языки, предоставляющие программисту всю свободу и ответственность, здесь наиболее эффективны.
> Подумать только, ТРИ типа!!!11 Наверное, они в ТРИ раза небезопаснее, чем в
> Си!!!11
Наверное указатели вообще не нужны для безопасного программирования! Наверное безопасная программа не должна заботиться об адресации каких-то байтов, а оперировать абстрактными типами, максимально защищенными от "дурака"! Не это ли есть типобезопасность!
> Возразить на что? На ваше голословное утверждение о том, что якобы "именно
> поэтому самые востребованные операционки написаны на Си"? у так папы юникса
> уже написали Plan 9, уже сделали попытку исправить свои ошибки и
> уже озвучили причины, по которым, на их взгляд, "востребованные операционки" остаются
> таковыми.
Ну и каковы же эти причины? "Ложь и самообман" разработчиков? :)
> Вы-то сами чем своё утверждение обосновали? Ничем. Вместо обоснований - переход на
> личность собеседника в нелестных эпитетах.
Замечу, что переход на личности начали именно вы.
