https://www.opennet.ru/openforum/vsluhforumID3/130313.html После года разработки опубликован релиз свободного набора компиляторов GCC 13.1, первый значительный выпуск в новой ветке GCC 13.x. В соответствии с новой схемой нумерации выпусков, версия 13.0 использовалась в процессе разработки, а незадолго до выхода GCC 13.1 уже ответвилась ветка GCC 14.0, на базе которой будет сформирован следующий значительный релиз GCC 14.1...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59038<br> https://www.opennet.ru/openforum/vsluhforumID3/130313.html#352 Sun, 07 May 2023 04:39:31 GMT &gt; Это считай руко%опство в проектах которые пишут несколько человек, и особенно в <br>&gt; разное время, и оно плохо плохо обнаружимо, и может даже вполне <br>&gt; работать.. пока не тронешь.<br><br>Мне пример этого интересен, как бы это могло выглядеть. Потому что сходу баг такого типа не припоминается особо. И хотелось бы понять как и почему это образуется и (если это выглядит правдоподобно) как этого можно было бы избегать.<br><br>&gt; Чужой код в принципе не бывает нормальным, и особенно тот в котором <br>&gt; попросили исправить "мелочи" или доработать. Шутка, но с долей правды.<br><br>На самом деле чужой код бывает очень разным. От г-на до мегарулеза. При том иногда все и сразу, за некоторый код хочется наградить кодера медалью и расстрелять.<br> https://www.opennet.ru/openforum/vsluhforumID3/130313.html#351 Fri, 05 May 2023 14:03:44 GMT Пакет под Альт Линукс есть или самому собирать, я про CudaText?<br> https://www.opennet.ru/openforum/vsluhforumID3/130313.html#349 Tue, 02 May 2023 09:35:39 GMT &gt;&gt; Вообще то, в первую очередь интересует отлов ошибочного присваивания не тому типу, <br><br>Это считай руко%опство в проектах которые пишут несколько человек, и особенно в разное время, и оно плохо плохо обнаружимо, и может даже вполне работать.. пока не тронешь. <br><br>&gt; В нормально написаном портабельном коде там вообще грабель не должно быть.<br><br>Чужой код в принципе не бывает нормальным, и особенно тот в котором попросили исправить "мелочи" или доработать. Шутка, но с долей правды. <br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/130313.html#348 Tue, 02 May 2023 00:49:09 GMT Ну так напиши майнер на фортране, посмотрим сделает ли он по мегахешам сишный.<br> https://www.opennet.ru/openforum/vsluhforumID3/130313.html#347 Tue, 02 May 2023 00:43:44 GMT &gt; Вообще то, в первую очередь интересует отлов ошибочного присваивания не тому типу,<br>&gt; хоть и того размера, а не приведения типов.<br><br>А что это за ситуации вообще? Мной это не распознается как какая-то типовая проблема, чтобы "в первую очередь" волновало. Нельзя ли конкретных примеров как, где и почему это является заметной проблемой?<br><br>&gt; Хотя в коде предназначенном для сборки для 32 и 64 битных систем,<br>&gt; грабли найдутся и там.<br><br>В нормально написаном портабельном коде там вообще грабель не должно быть. Для себя я предпочитаю C99 и конкретные размеры типов, для точно определенного диапазона значений, так что платформа либо предоставляет мне ЭТО либо "out of luck" (с 99го года почти четверть века прошла).<br><br>&gt; Но, поскольку лучше по максимуму отловить проблемы на стадии компиляции, а не <br>&gt; из багрепортов, то мне более приемлимы "бестолковые" предупреждения.<br><br>Я даже false alarm статических анализаторов затыкаю. Потому что не прочь поразвлечься всяким микроконтроллерным и управляющим и последнее что я хочу https://www.opennet.ru/openforum/vsluhforumID3/130313.html#346 Tue, 02 May 2023 00:29:00 GMT &gt; "Я захотел нарушить конвенцию, но виноват вон тот".<br><br>В реально требовательных штуках, типа MISRA, насколько я помню, конвенция такова что на использование макро накладываются крайне жесткие ограничения, так что вон то использование (function-like macro) будет под запретом. Во избежание вот этого вот всего вообще крайне радикальным методом.<br><br>А ваша конвенция - вообще чья и как сформулирована? Она задекларена в каком-то стандарте или устоявшемся гайдлайне? У реально критичных предпочитают совсем не связываться с макро по возможности. Менее радикальные, которые хотят более читаемый код но не баги, обучаются обкладывать козлаW матом^W^W макросы скобками.<br><br>И таки если вместо 1 строки (т.е. макро с 2 выражениями) станет 3 - код станет более рыхлым и это тоже испортит его восприятие. Может прибавиться ситуаций "функция не умещается на экран", что тоже баги вызовет. А, да, у тех кому критично есть довольно жесткие лимиты на размеры и сложность функций, так что +3 строки тоже так то трабла.<br><br>Есть еще вызовы ф https://www.opennet.ru/openforum/vsluhforumID3/130313.html#345 Tue, 02 May 2023 00:12:38 GMT &gt; В программах на Си для реального режима x86 дальние (far) указатели представлены <br>&gt; парой шестнадцатибитных чисел &#8212; селектором и смещением.<br><br>Интересно насколько вообще то нечто вообще соответствовало каким либо стандартам си.<br> https://www.opennet.ru/openforum/vsluhforumID3/130313.html#343 Mon, 01 May 2023 07:51:13 GMT То, что вы хотите от semver чего-то, что он не может &#8212; не проблема semver, это ваша проблема.<br> https://www.opennet.ru/openforum/vsluhforumID3/130313.html#342 Mon, 01 May 2023 07:33:49 GMT &gt;&gt; Да, 90% бестолковых предупреждений, <br>&gt; Вообще-то вполне толковых, <br><br>Вообще то, в первую очередь интересует отлов ошибочного присваивания не тому типу, хоть и того размера, а не приведения типов. Хотя в коде предназначенном для сборки для 32 и 64 битных систем, грабли найдутся и там.<br>Но, поскольку лучше по максимуму отловить проблемы на стадии компиляции, а не из багрепортов, то мне более приемлимы "бестолковые" предупреждения. И исходник считается вменяемым, если нет предупреждений при включении практически всех опций, кроме Wpedantic.<br>