Средства и методы разработки

Я уже высказывался, что 2/3 MISRA правил считаю попросту бредовыми очень странными. Я понимаю, почему некоторые из них возникли, какие причины были. Но нужно либо уметь сказать, что данные причины мы считаем несущественными (возможность выстрелить себе в ногу) для профессиональных программистов (она попросту нужна эта возможность) -- MISRA здесь огораживает студентов от опасных возможностей, либо причиной является отсталость от современных стандартов и низкое качество компиляторов и C-библиотеки. Но подход MISRA он очень странный: они запрещают одно, другое, третье и не дают решения, а что использовать вместо запрещаемого. Предполагается, что программисты это из головы выдумают. Так вот это действительно плохой подход, потому, что что-то своё, новое, вот так взять и выдумать из головы, и ещё качественно реализовать куда сложней, чем повторить уже готовые решения, или просто взять готовое. Например, запрещают malloc и побуждают писать свой аллокатор. Это что, решение? Качественный аллокатор достаточно сложен. В данном примере запрещают time и предлагают использовать свои самодельные функции? Сколько мы видели некачественных C-библиотек с плохим аллокатором, с плохо реализованными функциями для работы с временем. Так вот самодельные решения изначально будут НЕ ЛУЧШЕ. Лучше они могут стать после нескольких лет обтесывания острых углов, и в коде, и в архитектурном плане. Поэтому, на мой взгляд, следовало бы выкинуть MISRA и взять общепринятые практики программирования для компьютеров вообще, а не замыкаться в мирке ембеддеда с нестандартными практиками программирования (да, важным недостатком MISRA является тот факт, что она побуждает к написанию непортируемого кода, и такого кода который нельзя тестировать на ПК и потом переносить на МК). То о чём пишет MISRA, почему они что-то запрещают, это обычно известные вещи и есть уже готовые решения и методики не выстрелить себе в ногу, есть качественные библиотеки и т.п. Что касается 32-битности, то даже в 2018 году мне она представляется отдалённой проблемой. Разрабатываемые приборы имеют какой-то срок службы, ну положим 10 лет. До 2036 года ещё не доходит. Конечно плохо это, но сейчас простых решений нет: у кого-то уже есть, конечно, 64-битное время, у кого-то нет и ещё долго не будет (но может быть беззнаковое время до ~2104 года). Кроме того, нужно чётко разделять разные "пространства времён" (time domains). Есть календарное время (wall clock), с ним проблемы. Есть монотонное время (от момента включения прибора, например). Нужно понимать, что wall clock может переводиться по указаниям партии и правительства, может подстраиваться, а монотонное время течёт именно что монотонно. И для организации логики работы прибора нужно последнее, для большинства функций, если они не привязаны к календарному времени, конечно. И с 32-битностью монотонного времени проблемы нет и не будет никогда.