> Есть такое.Ну вот временами ISO очень хочется дать в репу за такие стандарты. Еще годике в 99 надо было сделать вон те C99 types основными, и все и вся на них завязать. Включая препроцессор и много чего еще.
Скажем какой тип у enum? А влезет ли вот этот enum в вот эту переменную? А как заранее узнать, м? Или круто когда вам signed постоянно пытаются подмахнуть, то в индекс массива, то в shift какой, где оно в процессе конверсии образовалось. Хотя остальная математика напрочь unsigned.
Чтобы не было скучно - shift'ы всякой негативщины UB а препроцессор имеет свое мнение на тип результата, как впрочем и enum-ы. Отличное от основной тушки при том. Круто потом бит микроконтроллеру не туда выставить, это, блин, системнее некуда. И критичнее некуда. И там вон те косяки так то проблема.
> Но _главное_ назначение Си - писать системный код.
И это последнее место где мы хотим прострелить себе пятку, потому что не загрузившийся бутлоадер, упавший кернел (не дай ктулху на управляюшем одноплатнике), взглюкнувшая управляющая фирмварь и прочие СИСТЕМНЫЕ вещи которые мы СЕЙЧАС используем - такое себе.
> То что на нем можно написать любую прикладную программу, хоть это и не будет продуктивным
> трудом, это побочный эффект.
Вот если обычная прикладуха упадет - да и черт с ней, перезапустим. А если это кернел, бут или фирмварь будет... эээ... и вот тут вон те свойства классического си так то подбешивают временами.
> Видел. Но это же и не платформа для портирования ядра Linux.
Из ядра линукс кто-то может какой-то код скопировать. Лицензия позволяет. Да и люди иногда линукс на реально странных вещах хотят. Одно время на blackfin DSP был, и техасских каких-то, все такое.
> И тем более не повод в исходнике предполагающем портирование не переопределить типы.
Вообще-то повод. Си до 99 было вообще невозможно предсказуемо пользоваится. И все адекватные кодеры изобретали нормальные ПРЕДСКАЗУЕМЫЕ типы вручную. C99 лишь внес порядок в этот хаос, конкретизировав один из вариантов как это делать как референс. И все.
Линукс кернел появился когда C99 еще не был в обиходе во всю, поэтмоу есть часть кода где оно увы такое какое есть.
> Писать в исходнике именно char, но использовать его с жесткой привязкой
> к платформе - верный путь остаться без премиии. ;)
Учить линуксоидов писать код - занятие неблагодарное. У них код системнее и качественнее большинства двуногих. В том числе и инструментированые метрики типа bugs/kloc это фиксируют.
> Те же грабли. Том 2й.
Ну вот поэтому я предпочитаю типы C99. Если я сказал uint8_t - я именно это и ожидаю. А не так чот мы тут поработаем полгодика в управляющей системе, но потом что-то в полнолуние високосного года навернется.
> на размеры системнозависимых типов. И как правильно писать переносимый между платформамии код.
Указатели в сях так то в целом достаточно грабельно сделаны, иногда даже матерые зубры простреливают пятки по глупому.
Что еще глупеее void something(uint8_t data[20]) - [20] чисто информативное и никак особо не используется для реальной верификации при сборке, как максимум это рантайм анализаторы типа asan/ubsan поймать могут, но это хуже чем отловить на фазе компила. На самом деле в сильно некоторых случаях оно и в компилтайм знает но там грабель немеряно.
Что еще интереснее, форснуть чтобы caller дал именно uint8_t[20] не так то просто и очевидно как это должно бы быть. А если он даст uint8_t[10] - ну, ой, так можно было, варнингов может и не быть - зато вооооот вам. В системщине это особенно пикантно так то.
> Элементарно. Достаточно писать в правильном стиле.
Ну я вот это корректно оформить смогу. А average joe сколько грабель откушает?
> И не поверите, исходники не обложены кучами ifdef'oв.
Да почему, поверю, ифдефы лишь 1 из опций.
> UART, а в другой сокеты, также нужны таймеры, миллисекундный источник времени,
> вывод то на spi-экранчик, а то дисплей, или интерфейс для Алисы,
> или ничего, и так далее.
Можно например договориться с собой что платформа предоставляет "драйвер" или "апи" этого, унутрях это их внутреннее дело. Мы дергаем какое-то абстрактное gpio_set_pin(USER_LED1). Как оно унутрях сделано caller'у не интересно и не накладывает лимитов на реализацию. Кто хочет может через файлы или ioctl linux, кто хочеь может запись в порт регистра. Лишь бы наружу тот же интерфейс светило.
> А вот как работать с разным ABI не погрязнув и в ifdef'ах?
Про вот именно ABI задумываться приходится довольно редко, и именно в глубокой системщине.
> Особенно в протоколах и форматах обмена. Правильнее хранить локальные данные в
> нативных форматах, в для тех же протоколов парсить и генерировать данные,
Это называется "сериализация-десериализация". Но к сожалению не халявно по ресурсам.
> надежнее написать генератор исходника, работающий по шаблонным поавилам, а не писать
> оптимизированные хаки на каждый чих.
Только потом в нем никто не разберется и майнтайнить это будет некому.
> Если обменяться идеями, прошу в личку.
А тут нет лички вроде бы.
> У плохого повара, всегда кастрлька виновата
Да вот знаете, с хорошим шмотом даже я - сносный повар, нажал эн кнопок, выбрал программу, дальше проц сам трекает термопрофайл готовки. Удобно, не надо над кастрюлей постоянно трястись да и термопрофайл проц сам подкрутит как надо. Что все же так то мило.
> Если бы он работал с электроникой, то распаяв и перенапаяв прибор как
> нибудь, он и интуитивно точно догадался бы, что работать не будет.
Да вообще иногда даже это прокатывает. Вон у ардуинщиков порой какие жуткие клубки проводов получаются. Иногда даже пашет. Если повезет еще и без глюков.
> Но почему то в программировании принято верить что написанное спустя рукава ну
> хоть как нибудь да заработает.
Может мне теперь DRC/ERC в KiCad не пользоваться и функциональность пинов не указывать? Посмотреть облажаюсь ли я своим ходом если сегодня не в ударе а интерконктов стало много. Разумеется если он взывал дальше уже мое дело чинить это/затыкать false alarm или забить. Но тут я уже не смогу сказать что меня не предупреждали. А вероятность что плата где DRC+ERC проехал заработает - и может быть сделана по вон тем нормам - заметно повышается.
> мере знать и другие платформы. Часто нужна математика, хотя бы на
> уровне первого курса.
Ну да, без этого совсем уж дохленько будет, даже PID контроллер какой осознать уже тяжко, а фурье там какое... но ведь даже ардуинщик не откажется так то спектр с микрофона или откуда там на экран или светодиоды раскинуть так то.
> Тут уж если полез в системное программирование, то сем себе яму и
> вырыл. Если язык небезопасный, и слишком много ньюансов приходится держать в
> голове, стоит задуматься о переходе на другой язык.
А тут как бы опций не сильно много и все со своими траблами. Я для себя предпочитаю C99/C11 + для мк гнутое расширение 0b.... для констант в виде именно кучки битов, если так визуальное представление лучше. Все же главное чтобы сорц читаемым и понятным был, иначе и я запуутаюсь и тем более те кто потом майнтайнить будет.
