>> А вы, продолжайте юлить и юродствовать - мне ваши и им подобные
>> опусы одно удовольствие разбирать.
> Ну, судя по тому, что вы не поленились написать ответ на один
> из этих "опусов" длиной аж в два экрана, вам их действительно
> удовольствие разбирать.Буквально это я и имел ввиду: удовольствие разбирать. Вы пришли, исказили смысл моих слов (неоднократно, и продолжаете это делать), не извинились, даже не поправились, договариваете и домысливаете за меня, уточняющих вопросов не задаёте, ведёте полемику, что-то безапелляционно постулируете, невнимательны, переходите на личности (видимо, наивно решив, что уж коли я высказался о вашей точки зрения в эпитетах а ля "чушь", то у вас есть морально-этическое право "рисовать" на меня оскорбительные словесные карикатуры: "встал в позу", "надул щёки" и т.д.), завышаете требования к качеству моей аргументации, хотя качество вашей к нему даже не приблизилось до сих пор.
Разумеется, мне одно удовольствие - разбирать ваш недалёкий троллинг в порядке оздоровительного конструктивно-праведного негодования. Буквально так.
> Пока что именно вы голословно заявляете о том, что якобы существуют какие-то
> более безопасные системы, написанные на каких-то более безопасных языках.
Я подобное не заявлял, потому как придерживаюсь противоположного мнения. Давайте-ка, подкрепите чем-либо очередные свои поспешные обвинения.
> Голословное утверждение. Давайте конкретно: какие ОС промышленного уровня, написанные
> не на Си, оказались более безопасными и по каким критериям?
В оберонах (семейство ОС) отсутствуют классы уязвимостей, свойственные системам на Си и обусловленные небезопасными типами в последнем. Вот вам критерий: нет переполнений буфера, ошибок в неконтролируемой арифметике указателей, утечек неинициализированных данных, мутабельных указателей на произвольные адреса и как следствие нет уязвимостей к выполнению произвольного кода через эксплуатацию ошибок перечисленных классов.
> Имелась ввиду не сложность работы со строками _вообще_, а сложность реализации этой
> работы применительно к конкретным областям. В частности мы говорили о "безопасных"
Дайте неформальное (хотя бы) определение "сложности работы" и "сложности реализации".
> ОС. Так вот работать со строками в Си не удобно, но
> их реализация крайне проста и наиболее близка к машинному представлению. В
Во-первых, о какой реализации речь - в системе выполнения языка? Думаю, вы не считаете, что простота реализации языка всегда важнее простоты программирования на нём - это слишком грубо. Но получается, что баланс между простотой реализации в Си и простотой программирования на нём вы считаете едва ли не идеалом, "аргументируя" это пространными суждениями о потери контроля, которые конкретики полностью лишены.
Во-вторых, нет никакого машинного представления по умолчанию. Простое представление строк в форме структуры размер+данные[+максимальный_размер], как в Аде и оберонах (например), позволяет всегда за O(1) получить длину строки (или массива), за O(1) размер выделенного буфера, за O(1) позволяет (в принципе) адресовать элемент строки по отрицательному индексу, осуществить автоматические проверки на выход за границы как на этапе компиляции, так и в рантайме.
Ваш "идеал" - представление, требующее прохода по элементам строки для получения её длины, для адресации по отрицательным индексам (арифметика указателей от конца строки), не позволяет выполнять автоматические проверки на выход за границы в рантайме, требует "таскать" за собой размер строки, чтобы упразднить его повторное вычисление и/или проверять на выход за границы вручную, и "таскать" его за собой в библиотечные API, и не иметь возможности проверить размер даже на этапе компиляции. И так далее (проблемы при оптимизации из-за алиасов указателей, проблемы с безопасностью, человеческие ошибки типа off-by-one и прочее).
Можете вы объяснить, чем такой "идеал" "ближе" к реализации? При том, что размеры строк либо неэффективно и небезопасно вычисляются, либо "таскаются" в структурах и аргументах - то есть в Си вы пишете так, как та же "Ада" пишет за вас. К операциям изменения длины строк (результатов операций со строками) в динамической памяти это тоже относится.
Я вам даже больше скажу - вы в libc (особенно в glibc) работаете со строками, неявно вызывая код на ассемблере внутри библиотечных функций, а вовсе не "гибкий" и оптимально скомпилированный код на Си. Ничто не мешает по нужде реализовать подобные ассемблерные вставки на той же Аде - причём, реализовать один раз в теле тех же библиотечных функций. И оптимизаций таких - легион. И не только в функциях со строками, но и в ядрах ОС, в криптографических библиотеках, в библиотеках потоковой обработки данных и так далее. Как портируемый и при этом эффективный "высокоуровневый ассемблер" Си себя не оправдал, невзирая даже на те деньжищи и усилия, которые на него потрачены.
> результате она оказывается более эффективной, чем реализация строк в Аде, которая
> а) скрыта от программиста, б) варьируется в зависимости от типа и
> в) варьируется в зависимости от компилятора.
Вот только эти мантры вы и в состоянии противопоставить. Ответ на которые один: читать спецификацию. Попробуйте собрать ядро линукса или любой из тройки *BSD TenDRA'ой или ICC *без* правок, которые специально для этого уже кое-где внесены в код разработчиками этих ОС. Или попробуйте собрать современные ядра линукса с gcc 2.95.
> Но люди продолжают и продолжают на этом писать! Неужели вы считаете, что
> все 100% этих программистов в течение многих лет продолжают заниматься самообманом?
Некоторые продолжают: расписывают во всяких features.html, какая их ОС замечательная в плане безопасности, а потом публикуется очередная уязвимость ядра, прямолинейная эксплуатация которой сводит на нет всё то, о чём в тех features.html поначиркано. Это FreeBSD.
Некоторые выпускают RELIABILITY FIX на уязвимость ядра, позволяющую локально получить привилегии root. Это OpenBSD.
А некоторым просто всё равно: они отвергают патчи, направленные на усиление защиты, в угоду убогим наследственным интерфейсам, которыми из всей user base пользуются только полтора разработчика. Это линукс.
А некоторые в смешанном духе FreeBSD и OpenBSD увлекаются дроблением ядра на компоненты, не учитывая уязвимости системы выполнения в Си при моделировании угроз и не вырабатывая никаких целевых механизмов защиты. Это Genode.
> :) Так можно и до теорий заговоров договориться...
Да, можно. Это называется reductio ad absurdum - дешёвая и, в вашем случае, неумелая полемика.
> Да, лишний код, и это не смешно. Если я работаю с динамическими
> строками сразу возникают проблемы распределения памяти и сборки мусора, которые неизбежно
> порождают лишний код.
Да, это не смешно. Это старая песня. На Си у вас память под строки святым духом выделяется и освобождается? Размеры буферов за вас Аллaх считает? И вызов функций (!) у вас каким-то чудом получается эффективнее "inline"-кода, встроенного в систему выполнения?
На сколько я знаю, идиоматические Си и C++ до производительности типобезопасных языков не дотягивают и прогрызают себе дорогу в том лишь ценой извращённых микрооптимизаций, зависящих от компилятора, а порой и от аппаратной платформы. У вас есть доказательства обратного? Какой-нибудь идиоматический код теста на C/C++, который рвёт всех в клочья на шутауте? Давайте посмотрим.
> Если в приложении этот код без проблем выполняет
> ран-тайм библиотека, то в ядре ОС управление этим кодом может стать
Какая-какая библиотека? Впрочем, важно другое: очевидно, что вы не работали со строками в ядре и несёте чепуху "от балды". А вот я работал и "наработался": чем ещё характерен Си, так это тем, что создавая код для усиления защиты в одном месте, увеличиваешь риск создания уязвимости в другом месте. Спросите любителей писать безопасный код на Си - разработчиков OpenBSD. Они вам скажут то же самое.
> головной болью программиста и, в конечном счете, привести к ослаблению безопасности.
"Головной болью" - это вы так обозначили необходимость думать и понимать, что делаешь, и как оно работает? Вот где "головная боль" - так это в Си. А вы говорите так, как будто думать нужно только в типобезопасных языках. В которых, кстати, вами любимое (?) ручное управление памятью тоже есть или может быть реализовано.
>> возникают? Насколько легко идентифицировать и исправить? Давайте сравнивать с Си.
> Давайте. Давайте для начала приведем примеры ОС, которые могут делать хоть что-нибудь,
> кроме как "быть безопасными", а потом посмотрим насколько не соответствуют этому
> призрачному идеалу реально существующие ОС.
Похоже, на заданные вопросы вы конкретно ответить не можете. Обероны - ОС, которые написаны не на Си и "могут делать хоть что-нибудь". Гуглите Bluebottle и Active Oberon.
> В Си спецификация очень проста - массив символов, заканчивающийся нулем. Все операции
А в Аде сложна? Обоснуйте, в чём сложность. "Скрыта от программиста" - не аргумент и даже не проблема. Ответы на все вопросы есть в спецификации на язык и документации к компиляторам. Плюс исходный код.
Вы разглагольствуете о непригодности типобезопасных языков для написания ядер ОС, а требования к языкам предъявляете на уровне быдлокодера - это ваше "скрыта от программиста".
> со строками самоочевидны. А вот что творит со строками Ада -
Самоочевидны - это не критерий, уж точно не при разработки ядра ОС. Да и самоочевидность эта заканчивается на теории и выливается в нескончаемые ошибки на практике.
> я не знаю. Да мне и не надо знать, если я
> пишу приложение. Но если это встроенная система, работающая на голом железе,
> то мне совсем не безразлично в какой момент компилятор захочет вызывать
> менеджер памяти или сборщик мусора.
Да уж куда вам знать-то. Не знаете даже, что в Аде преобладает ручное, либо явно обусловленное управление памятью, и что поведение сборщика мусора можно контролировать явно.
Да и обероны существуют, вопреки вашей пустой схоластике. XOberon/2 и HeliOS - ОС реального времени с промышленным применением. И вот в них-то как раз сборка мусора преобладает. Факты - они упрямы.
> Если бы в С++ была приемлемая реализация строк, мы бы не наблюдали
> того зоопарка строковых библиотек, который поставляет со своими продуктами каждый разработчик
> компиляторов.
В C++ хотя бы есть юзабельные альтернативы. Хотя бы. В "гибком" Си и того нет.
> Это какие ядра собираются разными версиями компиляторов? Примеры, пожалуйста.
Новые линукс-ядра старыми версиями GCC (2.x) либо не собираются, либо не работают. При том что GCC 2.95 до сих пор собирает, например, ядра OpenBSD для некоторых старых архитектур.
> Слабость вашей позиции в том, что вы воспринимаете безопасность кода как единственный
> критерий эффективности системы. Причем даже не безопасность вообще, а почему-то именно
Слабость вашей позиции в том, что вы не вдумываетесь, не понимаете и не спрашиваете, чтобы уточнить позицию собеседника. И несёте чушь, которую даже опровергать не нужно - достаточно спросить с вас цитаты, где я якобы высказывал такое-то мнение.
Спрашиваю: где я говорил, что "безопасность кода" - это "единственный критерий эффективности системы"?
А смысл моей позиции в следующем: небезопасность кода обуславливает небезопасность системы. Всё. И для ясности: безопасность кода необходима, но не достаточна для обеспечения безопасности системы.
> типобезопасность! В этом есть некий солипсизм. Реальность же такова, что абсолютно
Ваше представление о реальности в части безопасности современных ОС общего назначения зациклилось где-то на середине 90-ых. Впрочем, вы не одиноки.
> безопасных систем не бывает, более того, в них нет необходимости! Сюрприз?
Действительно, сюрприз. Очередной виток спирали ваших глупых опровержений вашей же убогой интерпретации смысла моих слов.
> Обычно требуется некий компромисс между определенным уровнем безопасности, скорости,
> потреблением ресурсов и т.п. Как показывает практика, языки, предоставляющие программисту
> всю свободу и ответственность, здесь наиболее эффективны.
"Как показывает практика" - и где же она это показывает? Вот когда я говорю, что практика показывает, что нет сложных и безопасных систем, работающих на уровне абстракций C/C++ - практика это действительно показывает на примере истории уязвимостей любой из таких публично доступных систем.
А вы видите на практике только то, что видите, в силу своего ограниченного кругозора. С чем вы сравниваете системы, написанные на Си? И не смущает ли вас, что о системах на типобезопасных языках вы спрашиваете меня?
>> Подумать только, ТРИ типа!!!11 Наверное, они в ТРИ раза небезопаснее, чем в
>> Си!!!11
> Наверное указатели вообще не нужны для безопасного программирования! Наверное безопасная
Любопытно было бы узнать: какая связь между указателями вообще и безопасным программированием? ;)
> программа не должна заботиться об адресации каких-то байтов, а оперировать абстрактными
Ясно. Об "умных" указателях вы тоже ничего не знаете.
> типами, максимально защищенными от "дурака"! Не это ли есть типобезопасность!
Типобезопасность бывает разной. И я об этом уже писал. И почему она не панацея - тоже писал, на примерах. Чукча не читатель?
> Ну и каковы же эти причины? "Ложь и самообман" разработчиков? :)
Причина в том, что существующие системы не настолько плохи, чтобы тратить ресурсы на замену их новыми.
> Замечу, что переход на личности начали именно вы.
Нет, переход на личности начали именно вы. Но, похоже, воспитание не позволяет вам видеть разницу между высказываниями в адрес мнений и в адрес собеседников.
