https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html Компания Coverity, развивающая инструментарий для автоматического анализа кода на предмет наличия проблем безопасности и ошибок представила (http://www.bradenton.com/2012/02/23/3896742/open-source-code-quality-on-par.html) очередной ежегодный <br>отчёт (http://www.coverity.com/library/pdf/coverity-scan-2011-open-source-integrity-report.pdf) (PDF, 550 Кб) с результатами изучения 37 млн строк кода из 45 наиболее активно разрабатываемых открытых проектов и 300 млн строк кода из 41 анонимного проприетарного продукта. В среднем, в открытых проектах было выявлено 0.45 дефектов на 1000 строк кода, для проприетарных продуктов данный показатель составляет 0.64, при этом средний показатель качества для всей индустрии разработки ПО составляет 1 ошибка на 1000 строк кода.<br><br><br><br>Система Coverity Scan была создана в 2006 году по инициативе Министерства национальной безопасности США для обеспечения и усиления безопасности информационной инфраструктуры Соединенных Штатов, в которой используются различны...<br><br>URL: http://www.bra https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html#239 Fri, 02 Mar 2012 21:04:14 GMT Иногда такие быстрые исправления ошибок просто пужают. <br><br>Вон, несколько лет назад, valgrind показывал, что в OpenSSL неинициализированная переменная, Debianовцы "исправили" ошибку, и всё было хорошо. А потом оказалось, что исходные переменные для создания ключей стали прогнозируемы. <br><br> https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html#238 Fri, 02 Mar 2012 19:06:15 GMT &gt; PS вообще проблема SQL-inject легко могла бы решиться если в СУБД запретить <br>&gt; несвязанные переменные.<br><br>Это константы запретить?<br>В java уже запретили что-ли?<br> https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html#237 Tue, 28 Feb 2012 15:06:52 GMT почему не проанализировали plan9? это ж цитадель высокой мысли и идеальных решений, настолько идеальных, что аж сферических. пишут ли там с ошибками? (прости господи меня за такое вольномыслие)<br> https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html#236 Tue, 28 Feb 2012 13:30:01 GMT Да. Но не только. Нужно ещё эту базу образцов составить, т.е. "научить". Сколько там ребёнка ложку учат держать, а читать-писать? Будет ли экономически выгодной система на обучение которой уйдут десятки лет? Сделать "эмулятор мозга" (т.е. саморазвивающуюся адаптивную систему) трудно не логически, для этого вся математика есть, а чисто физически сложно добиться такой плотности связей и такой чувствительности, а значит способности к обучению.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html#235 Tue, 28 Feb 2012 13:05:39 GMT &gt; Ну теперь я не удивляюсь тому, как в Linux относятся к звуку. <br><br>нашёл кому верить. видишь же: на просьбу показать конкретный код чувак слился и не отсвечивает.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html#234 Tue, 28 Feb 2012 12:53:37 GMT &gt; Все просто - не инициализированные переменные активно используются.<br>&gt; Есть специальная техника - туннелирование.<br>&gt; Позволяет передавать значения переменных в функцию без дополнительных затрат времени. <br><br>Это должно работать очень ненадёжно.<br>Gcc любит оптимизацию работы со стеком следующим образом: возврат позиции SP (ESP, RSP - неважно) после каждой функции не делается, а делается только в конце. При нескольких последовательных вызовах позиция SP будет постепенно уползать влево. Это частично отключается в случае вызовов внутри цикла (SP на входе в цикл должен иметь всегда одно и то же значение), но при линейных вызовах позволяет экономить операции.<br>При такой оптимизации адреса для f1.a и f2.h будут разными, и передача данных не случится.<br> <br>&gt; Очень активно используется в ядре линукс. Также почти все звуковые драйверы написаны <br>&gt; подобным образом, но это скорее по историческим обстоятельствам.<br>&gt; Метод работать то работает, только надежности не прибавляет.<br><br>Ну теперь я не удивляюсь тому, как в Linux о https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html#233 Mon, 27 Feb 2012 21:15:08 GMT боксинг &#8212; это фишка VM. которая (VM) не позволяет передавать указатели/ссылки на элементарные типы. равно как и closures &#8212; фишка VM, потому что надо поддерживать обращение к вышележащим фреймам и их копирование.<br><br>не спорь, пожалуйста &#8212; вряд ли ты занимался написанием VM. я &#8212; занимаюсь, лет уж&#8230; в общем, не цифрой выражается.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html#232 Mon, 27 Feb 2012 20:57:23 GMT &gt; там для начала неплохо было бы саму JVM починить, с её боксингом <br>&gt; всего и вся. а также приделать туда нормальные замыкания и TCO. <br>&gt; концепциям сто лет в обед, а без костылей никак. ужас.<br><br>боксинг это фишка компилятора. синтаксичекий сахарок.<br><br>замыкания в прочем тоже сахар.<br><br><br> https://ssl.opennet.dev/openforum/vsluhforumID3/83252.html#231 Mon, 27 Feb 2012 20:55:21 GMT &gt;&gt; Начнем с начала, что в реал-тайме вообще выделение/освобождение не должны применяться. А в идеале запрещены.<br>&gt; мне в реалтайме нужно обрабатывать поступающие из очереди запросы. И как я <br>&gt; это сделаю не выделяя/освобождая память, если я не знаю, сколько памяти <br>&gt; потребуется для обработки запроса, пока его не заберу?<br><br>Предварительное аллоцирование по максимально возможному размеру запроса. В RT все равно не будет мегабайтных XML-партянок, потому по ТЗ можно заранее предсказать размер и аллоцировать нужное количество.<br><br><br>PS Для soft real-time есть еще один вид тредов (помимо базовых и hard real-time).<br>