https://www.opennet.me/openforum/vsluhforumID3/121274.html Разработчики мобильной операционной системы "Аврора" (локализованный вариант ОС Sailfish, развиваемый компанией "Открытая мобильная платформа") поделились показательной историей об устранении критической уязвимости (CVE-2020-6096) в Glibc, проявляющейся только на платформе ARMv7. Сведения об уязвимости были раскрыты ещё в мае, но до последних дней исправления не были доступны, несмотря на то, что уязвимости присвоен высокий уровень опасности и доступен рабочий прототип эксплоита, позволяющий организовать выполнение кода при обработке в функциях memcpy() и memmove() определённым образом оформленных данных. Исправления пакетов для Debian и Ubuntu не выпущены до сих пор и уязвимость остаётся неисправленной почти два месяцев с момента публичного раскрытия и пять месяцев с момента уведомления разработчиков Glibc...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53371<br> https://www.opennet.me/openforum/vsluhforumID3/121274.html#158 Fri, 24 Jul 2020 10:06:59 GMT Вы знаете у меня то же иногда возникают подозрения. Сами закладывают, и потом сами же выкатывают устранения уязвимостей. Однажды прогнал через шланг btusb.c (драйвер из ядра линукс) - нашёл два места обращений явно за пределы массива, и это в статике! И заметте, многие PR висят годами и никто не чешится их применять, хотя очевидно исправляют какую либо проблему.<br> https://www.opennet.me/openforum/vsluhforumID3/121274.html#157 Thu, 23 Jul 2020 14:42:09 GMT Какже достали все эти интовые наследия!<br>int main(...int argc) // ok, ребята, нам прислали -5 аргументов, держитесь!<br> https://www.opennet.me/openforum/vsluhforumID3/121274.html#156 Mon, 20 Jul 2020 21:23:03 GMT ОС Аврора такая же красивая, как её название?<br> https://www.opennet.me/openforum/vsluhforumID3/121274.html#155 Fri, 17 Jul 2020 17:50:09 GMT &gt; дальше не стал читать...<br><br>А зря. Там слёзная история как их все игнорят.<br> https://www.opennet.me/openforum/vsluhforumID3/121274.html#154 Fri, 17 Jul 2020 16:16:57 GMT &gt; ты то дохрена разбираешся, ни одного толкового ответа<br><br>Толковые ответы вы уже не раз получили. Раз не смогли нормально отреагировать, то теперь получайте вариант для чайников и не жалуйтесь.<br><br>А разбираюсь достаточно, чтобы писать и отлаживать код и на ассемблерах, и на Си, и на высокоуровневых языках. Вот только это не я тут заявляю, что Си &#8212; дурацкий язык с дурацкими компиляторами, которые ВНЕЗАПНО не умеют генерировать идеальный код.<br><br>&gt; вот ведь, оказывается можно писать на С.<br><br>Ну да, обернули каждую команду SSE в сишную функцию, а потом делаем вид, что программируем на Си, и, вдобавок, продолжаем полагаться на эффективность компилятора.<br><br>Ещё раз говорю: возьмите чисто сишную реализацию memcpy (можно этот код), скомпилируйте, отправьте результат в дизассемблер (вы же objdump пользоваться умеете, правда?) и сравните с &#171;ручной&#187; реализацией хоть из того же glibc. А потом производительность сравните. Вопросы отпадут.<br><br>Если же не можете сделать даже это, то перестаньте придуриваться и https://www.opennet.me/openforum/vsluhforumID3/121274.html#153 Fri, 17 Jul 2020 12:58:30 GMT Для случаев которые происходят гораздо чаще других. В редких он вполне может медленнее варианта на Си. В том и разница, что компилятор не способен оценить вероятность использования не проанализировав возможность взаимодействия каждой строчки программы с каждой. Пример: код printf("%s\n", "Hello, World!"); развернётся в множество больших функций, а на Ассемблере это всего 4 машинные инструкции. Когда компилятор может проанализировать вероятности, то его код безусловно будет лучше полуобщего ассемблерного варианта.<br> https://www.opennet.me/openforum/vsluhforumID3/121274.html#152 Fri, 17 Jul 2020 10:55:32 GMT &gt;Вы ещё и в компиляторах, значит, не разбираетесь...<br><br>ты то дохрена разбираешся, ни одного толкового ответа, все какието съезды про то как все трудно.<br><br>&gt;Идите, покажите, как надо.<br><br>5 минут поиска выдали вот такой проект - https://github.com/skywind3000/FastMemcpy/blob/master/FastMemcpy.h<br><br>вот ведь, оказывается можно писать на С. <br> https://www.opennet.me/openforum/vsluhforumID3/121274.html#151 Fri, 17 Jul 2020 10:25:14 GMT И-и-и-, тот memcpy в новости на асме для конкретного случая, или для всех на свете, где glibc будет использоваться?<br> https://www.opennet.me/openforum/vsluhforumID3/121274.html#150 Fri, 17 Jul 2020 09:40:51 GMT Вы ещё и в компиляторах, значит, не разбираетесь... Идите, покажите, как надо. Тысячи разработчиков компиляторов по всему миру ведь явно такие тупые, что за более чем полвека не смогли &#171;нормальный&#187; компилятор сделать, который бы все чаяния программиста угадывал.<br><br>Вам Ordu уже детально расписал конкретно по memcpy, сколько там нюансов. И это лишь одна из множества типовых операций, выполняемых программами.<br><br>Может быть, вы не в курсе, но при разработке компилятора скорость конечного кода имеет не наивысший приоритет. Куда важнее корректность и полнота реализации языка. А сами по себе языки программирования служат задаче уменьшения времени и сложности разработки. Вы же как пользователь предпочтёте работающую, пусть и не идеально быстро, программу сейчас, чем идеальную примерно никогда? Вот и придумывают порой жутко неэффективные (по сравнению с чем-то там), но работающие здесь и сейчас инструменты.<br>