https://www.opennet.me/openforum/vsluhforumID3/106073.html Дэниэл Бернштейн (Daniel J. Bernstein (http://cr.yp.to/djb.html)), известный эксперт в области криптографии и создания защищённого ПО, разработавший такие проекты, как qmail, djbdns, Ed25519, Curve25519 и ChaCha20-Poly1305, предложил (https://groups.google.com/forum/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ) создать новый компилятор для языка Си, рассчитанный на сборку защищённого ПО. По мнению Бернштейна сообществу не хватает компилятора, который мог бы обеспечить предсказуемое поведение и предоставить чётко определённую семантику для всех ситуаций, отмеченных в стандарте Си как неопределённые (undefined (https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D1%91%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D0%BE%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5)), неспецифицированные (unspecified) или зависящие от конкретных реализаций. <br><br><br><br><br>Большинство приложений используют подобные возможности, но существующие компиляторы могут трактовать их по разному, что может привести (https://www.op https://www.opennet.me/openforum/vsluhforumID3/106073.html#184 Fri, 07 Jul 2017 14:37:47 GMT все, кто там вякает, что типа "язык СИ хуже моего любимого бренфака" - назовите хоть одну нормальную прогу, написанную НЕ НА СИ. И чтобы она ещё решала задачку нормальной сложности, типа openssl, ffmpeg, qemu, а не просто набор скриптов типа docker.<br> https://www.opennet.me/openforum/vsluhforumID3/106073.html#183 Mon, 18 Jan 2016 09:35:55 GMT "Дураку" дай хоть танк - он его угробит. <br><br>По факту проблема не в языках, а в отсутствии грамотных СИСТЕМНЫХ программистов, способных писать алгоритмы с нуля и понимать каждую написанную строку кода. <br>Недавно посещал универ - искал ребят на проект - из потока в 30 человек - алгоритмы бинарного поиска знают и понимают 5ро!! (facepalm), остальные дубы дубами - пребывающие в заблуждениях что КТО-ТО для них должен сделать все, как то - разработать язык так сказать, без "архитектурных проблем" связанных с с указателями и т.п. И сядут они ЛАБАТЬ свои поделки... <br>Про Ассемблер тут я вообще молчу. <br>ТОлько не надо опять горло драть про скорости разработки и т.п. Скорость нужна при ловле блох, разработке пользовательских интерфейсов и конечного софта для клиента. Но никак не в разработке концептуальных/основополагающих библиотек.<br>Да и спешка сейчас привела к деградации качества программного обеспечения, как со стороны обучения программистов, так и со стороны разработки реально новых концепций. Хотя заглядывая https://www.opennet.me/openforum/vsluhforumID3/106073.html#182 Sat, 16 Jan 2016 14:52:21 GMT Такой компилятор, а точнее язык, уже есть - C99 :) Левое какое-то предложение. Unspecified или undefined означает, что не нужно рассчитывать на реализацию архитектуры, используемой разработчиком. На другой версии или архитектуре может быть не так. Так что лучше просто инициализировать переменные и избегать любых неоднозначных моментов по стандарту.<br> https://www.opennet.me/openforum/vsluhforumID3/106073.html#180 Wed, 30 Dec 2015 18:30:52 GMT Просто он предлагает выпустить компилятор с дополнительными замечаниями типа:<br> Daniel J. Bernstein warns that ...<br>Хочешь - избавляйся от них, хочешь - нет.<br><br>Я так понял.<br> https://www.opennet.me/openforum/vsluhforumID3/106073.html#179 Tue, 29 Dec 2015 14:41:27 GMT А потом получается жутко неудобный и костыльный epoll(), чисто потому, что делать как в kqueue() ему не хотелось - чо, имеет же право делать по-своему, а не как в BSD ? Имеет! И пофиг, что получается не прогресс, а "назло мамке уши отморожу".<br> https://www.opennet.me/openforum/vsluhforumID3/106073.html#178 Mon, 28 Dec 2015 05:57:29 GMT Как можно с бестыжей рожей утверждать, что всякие Дэ и Го со своими сборщиками мусора хоть когда-нибудь смогут достичь производительности и потребления памяти Си<br> https://www.opennet.me/openforum/vsluhforumID3/106073.html#173 Thu, 24 Dec 2015 21:51:01 GMT Google: nasa mars java <br> https://www.opennet.me/openforum/vsluhforumID3/106073.html#172 Thu, 24 Dec 2015 21:08:14 GMT Как можно с бесстыжей рожей называть себя "экспертом" и при этом предлагать полную ахинею в свете существующего языка D? Ну ладно, го-расты тоже в счёт. То есть чувак не знает, что "альтернатива Си" существует лет так 15??<br> https://www.opennet.me/openforum/vsluhforumID3/106073.html#171 Thu, 24 Dec 2015 12:40:12 GMT &gt;[оверквотинг удален]<br>&gt;&gt; int const* ptr2; // то же самое <br>&gt;&gt; int* const ptr3; // указатель на int, значение по указателю менять можно, но сам указателю менять нельзя <br>&gt;&gt; const int* const ptr4; // ничего менять нельзя <br>&gt; Т.е. всё, что находится до *, относится к типу объекта, на который <br>&gt; указывает указатель. Всё, что после - к самому указателю. Это правило <br>&gt; действует и при более высоких уровнях индирекции.<br>&gt;&gt; int** pptr1; // указатель, который указывает на указатель на int <br>&gt;&gt; const int** pptr2; // указатель, который указывает на указатель на const int <br>&gt;&gt; const int* const* pptr2; // указатель, который указывает на константный указатель на const int <br>&gt;&gt; const int* const* const pptr2; // константный указатель, который указывает на константный указатель на const int <br><br>премного благодарен за растолкованные нюансы и ваше время, особенно в случае const - теперь все более проще и понятнее<br><br>Действительно, int* защита фактически от случайной ошибки - довольно удобно. Насчет const - фактически это ук