The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз ядра Linux 6.2, opennews (??), 20-Фев-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


107. "Релиз ядра Linux 6.2"  +1 +/
Сообщение от _kp (ok), 20-Фев-23, 18:05 
Хороший СИСТЕМНЫЙ компилятор должен реализовать строго то, что просил автор.
Если автор чудит, то это неосознанный выбор автора, и его право. :)
Ответить | Правка | Наверх | Cообщить модератору

222. "Релиз ядра Linux 6.2"  +2 +/
Сообщение от Аноним (-), 21-Фев-23, 01:34 
> Хороший СИСТЕМНЫЙ компилятор должен реализовать строго то, что просил автор.

Проблемав в том что в C строго - понятие растяжимое из за лени авторов стандарта. Там очень много чего - UB. Или так определено что капец просто.

Скажем никогда не видел систему где char 16 битный? Это вполне валидно, по стандарту. Он реально занимает 2 байта, и некоторые DSPшники не умеющие в адресацию менее чем 16 битов это еще и практикуют. В чем проблема? Ну вы можете себе представить какой процент кода допускает что char именно такой и работает корректно, угумс...

А как вам 16-битные int? Это тоже ничему не противоречит. И по стандарту так вроде можно. Ну вон в атмелках каких это себе даже можно заказать. Потом правда будет примерно как выше - а какой процент кода корректно с этим работает?! Но формально ничего не предъявишь, стандарт позволяет.

А теперь коронный номер: попробуй это корректно по коммуникационному протоколу другим системам передать, во. В вот таком виде. И чтоб твой код в вон тех допущениях не помер, а на другой стороне линка поняли что ты передал и однозначно интерпретировали это. Что, все еще хочется такими типами оперировать? :)

> Если автор чудит, то это неосознанный выбор автора, и его право. :)

Одно дело если он в курсе что чудит и совсем другое если чудит вместо него компилер и implementation specific behavior а автор даже не знает что он - чудак.

Ответить | Правка | Наверх | Cообщить модератору

239. "Релиз ядра Linux 6.2"  +1 +/
Сообщение от _kp (ok), 21-Фев-23, 03:57 
> Проблемав в том что в C строго - понятие растяжимое из за
> лени авторов стандарта.

Есть такое.
Но _главное_ назначение Си - писать системный код. То что на нем можно написать любую прикладную программу, хоть это и не будет продуктивным трудом, это побочный эффект.


> Скажем никогда не видел .. char 16 битный?  это еще и практикуют.

Видел. Но это же и не платформа для портирования ядра Linux.
И тем более не повод в исходнике предполагающем портирование не переопределить типы. Писать в исходнике именно char, но использовать его с жесткой привязкой к платформе - верный путь остаться без премиии. ;)

> А как вам 16-битные int?

Те же грабли. Том 2й.
И сейчас любилели 32х битных указателей дописывают том 3й.
Хотя ещё в 90х, даже на русском было написано, что нельзя полагаться на размеры системнозависимых типов. И как правильно писать переносимый между платформамии код.

> А теперь коронный номер: попробуй это корректно по коммуникационному протоколу другим системам
> передать, во. В вот таком виде. И чтоб твой код в
> вон тех допущениях не помер, а на другой стороне линка поняли
> что ты передал и однозначно интерпретировали это. Что, все еще хочется
> такими типами оперировать? :)

Элементарно. Достаточно писать в правильном стиле.

Ну как пример, я пишу сейчас библиотеки для DLMS/COSEM. Там и протоколы, и базы, преобразования их одного в другое.
А собираеются проекты под STM32, ESP32, китайские Vango, Windows 64bit, Linux ARM, Mac M1 и Mac PowerPC. Распберри и PowerPc скорее для спортивного интереса, но завелось же.
А в этом случае еще помимо каких то типов, разных ABI, еще и разные ОС, и их отсутствие.
И не поверите, исходники не обложены кучами ifdef'oв. А работа на одной платформе с Eeprom, на другой с SDкартой, а следующей файлом( а в разных ОС и это по своему), или в одной платформе UART, а в другой сокеты, также нужны таймеры, миллисекундный источник времени, вывод то на spi-экранчик, а то дисплей, или интерфейс для Алисы, или ничего,  и так далее.
Кратко, ОС специфичные функции вынесены в отдельные файлы, интерфейсы взаимодействия с пользователем - отдельные, и нативные функции вызываются только через функции-обертки или заглушки, что б и исходнике их не было, так исключается привязка и именам функций и структур ОС, и основная часть исходников пересобирается без правки, даже при переезде на очередную платформу, и не нужно искать сюрпризы в уже написанном коде.
Очевидно, что платформозависимые типы в исходниках не используются.
А вот как работать с разным ABI не погрязнув и в ifdef'ах? Особенно в протоколах и форматах обмена. Правильнее хранить локальные данные в нативных форматах, в для тех же протоколов парсить и генерировать данные, но не соваться переставлять байты и считать биты "вручную". Если хочется переоптимизированного исходника, что для "протоколов уже излишне", но если надо, то надежнее написать генератор исходника, работающий по шаблонным поавилам, а не писать оптимизированные хаки на каждый чих.
Если обменяться идеями, прошу в личку.


> другое если чудит вместо него компилер и implementation specific behavior

У плохого повара, всегда кастрлька виновата, в том числе и когда дело именно в ней. И этим злоупотребляют, делая её виноватой во всех бедах до того, как разобраться.

> не знает что он - чудак.

Если бы он работал с электроникой, то распаяв и перенапаяв прибор как нибудь, он и интуитивно точно догадался бы, что работать не будет. (а когда точно должно работать, но не работает, это другое)
Но почему то в программировании принято верить что написанное спустя рукава ну хоть как нибудь да заработает.

Системный язык хоть и оперирует отдельными байтами и битами, но системный программист должен не только представлять продукт целиком, но и то как он взаимодействует с другими системами, а для этого надо в какой то мере знать и другие платформы. Часто нужна математика, хотя бы на уровне первого курса.
Тут уж если полез в системное программирование, то сем себе яму и вырыл. Если язык небезопасный, и слишком много ньюансов приходится держать в голове, стоит задуматься о переходе на другой язык.


Ответить | Правка | Наверх | Cообщить модератору

358. "Релиз ядра Linux 6.2"  +1 +/
Сообщение от Аноним (-), 22-Фев-23, 21:31 
> Есть такое.

Ну вот временами 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.... для констант в виде именно кучки битов, если так визуальное представление лучше. Все же главное чтобы сорц читаемым и понятным был, иначе и я запуутаюсь и тем более те кто потом майнтайнить будет.

Ответить | Правка | Наверх | Cообщить модератору

379. "Релиз ядра Linux 6.2"  +/
Сообщение от _kp (ok), 23-Фев-23, 12:27 
>>

Это называется "сериализация-десериализация". Но к сожалению не халявно по ресурсам

Это если на каждый чих буфера выделять, то не халявно.
А если как с потоком работать, передавая указатели на функции преобразования, то можно и без буферов и их копирования обойтись, делая всё на лету, в том числе в обработчиках прерываний на микроконтроллерах.
Потом бывают упакованные данные или значительные объёмы, которые на мелких контроллерах просто не влезут ни в какие буфера.
Но есть недостаток. Если писать на c++, или на Си, но именно gcc, то всё читаемо и хорошо. На на "обычном абстрактном Си" будет гадость, а не исходник.

Ответить | Правка | Наверх | Cообщить модератору

404. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (-), 24-Фев-23, 03:17 
>> Это называется "сериализация-десериализация". Но к сожалению не халявно по ресурсам
> Это если на каждый чих буфера выделять, то не халявно.

Это не имеет отношения к выделению буферов. Вот смотри, прямо сейчас у меня есть буфер который я бы хотел рассматривать и как u8[N] и как u32[N/4], тот случай когда раз в год и union мог бы иметь пойнт. Но на самом деле меня вообще вся пачка битов интересовала. Я бы вкатил им union так то, но u32 может быть как big-endian так и little endian, и вот тут я грабелек откушаю оптом и в розницу. И вот именно совершенно халявного (по объему кода и скорости) решения на такие ситуации может и не быть. Даже просто портабельно записать в файл или провод u32 - не, как просто единичная операция это сразу же познакомит нас с Endianess платформы и с тем фактом что она разная бывает.

> А если как с потоком работать, передавая указатели на функции преобразования, то
> можно и без буферов и их копирования обойтись,

Дело не в буферах а в именно "функциях преобразования" так то. Одно дело послать поток как есть. На мк каком - я вообще DMA заряжу, скажу "вгрузи от сих до сих" и забуду об этом, он мне скажет когда готово дернув IRQ а я пока чем-нибудь еще займусь. Это будет просто, круто и быстро. Я просто пульну фоновую операцию, и забуду о ней, потом железка дернет меня IRQ по transfer completion. Но вот с "функциями преобразований" это все уже - сами понимаете, вообще совсем не то. И если на десктопе с кучей ядер и гигагерц иногда катит и так, на мелочи где мегагерцев и памяти мало а поток данных может быть сравним с скоростью проца, потому что не факт что он высокочастотный, да и батарейки жрать не есть хорошо...

> делая всё на лету, в том числе в обработчиках прерываний на микроконтроллерах.

В DMA зарядить так то прикольнее. Почему-то. А обработчик так то только IRQ дернет. Кстати на десктопе в таком стиле тоже можно, если тредов себе завести, IO thread'ы смогут что-то наподобие. Там уже можно интеллект проявить, но опять же преобразования на высокой скорости не бесплатны по ресурсам.

> Потом бывают упакованные данные или значительные объёмы, которые на мелких контроллерах
> просто не влезут ни в какие буфера.

Я иногда балуюсь с DMA half-transfer IRQ: пока железка шлет/получает вон то я в софте жую новый субблок. Параллельно с этим. А что, двойная буферизация это круто.

> Но есть недостаток. Если писать на c++, или на Си, но именно
> gcc, то всё читаемо и хорошо. На на "обычном абстрактном Си"
> будет гадость, а не исходник.

Ну а вот привязываться навечно к 1 компилеру все же - ну так себе. Некрирые вещи из GCC явно стоило бы в стандарт загнать. Особенно case ... switch для диапазона, допустим. Стандартный код выглядит более криво чем с диапазонами в кейсе.

Ответить | Правка | Наверх | Cообщить модератору

380. "Релиз ядра Linux 6.2"  +/
Сообщение от _kp (ok), 23-Фев-23, 12:37 

>>генератор исходника, работающий по шаблонным правилам
>Только потом в нем никто не разберется

А вот это задача не для Си подобных языков. Быстродействие здесь ни разу не нужно, а нужна только возможность написать читаемый и лаконичный исходник.
Я использую для подобного Яваскрипт обычно, если кому то по душе Питон, то и он уместен.

Ответить | Правка | К родителю #358 | Наверх | Cообщить модератору

405. Скрыто модератором  +/
Сообщение от Аноним (-), 24-Фев-23, 03:23 
Ответить | Правка | Наверх | Cообщить модератору

382. "Релиз ядра Linux 6.2"  +/
Сообщение от _kp (ok), 23-Фев-23, 16:30 
>> Вон у ардуинщиков порой какие жуткие клубки проводов получаются. Иногда даже пашет.

У ардуинщиков и распберристов, тех кто с железом работает, обычно сборка из готовых библиотек. Чего то оригинального из софта там не так много.
А вот библиотеки для Ардуин вполне годный пример, когда очень часто пишут код который можно собрать не под конкретную железку, а чтоб работало на разных платформах.
Но если с типом char там проблем и нет, то с типом int вполне часто встречаются грабли, при переносе кода на 64 битные железки.

Ответить | Правка | К родителю #358 | Наверх | Cообщить модератору

406. "Релиз ядра Linux 6.2"  +2 +/
Сообщение от Аноним (-), 24-Фев-23, 03:30 
> У ардуинщиков и распберристов, тех кто с железом работает, обычно сборка из
> готовых библиотек. Чего то оригинального из софта там не так много.

Раз на раз не приходится. Вон там например FM трансмиттер через GPIO - довольно концептуально так то. И либой его такой не прицепишь, если это первый человек которому оно в голову пришло.

> код который можно собрать не под конкретную железку, а чтоб работало
> на разных платформах.

Увы, цена за это - крайне неэффективный код. Обставить их иной раз раз в 20 по скорости совершенно не проблема. А на какой-нибудь машке лапками GPIO это так то может быть весьма критично. За это опытные кодеры под AVR ардуино не жалуют. Мягко говоря. Урезает возможности чипа буквально в разы.

> Но если с типом char там проблем и нет,

Вообще, то что он может быть signed или unsigned и даже с разным числом битов - бардак.

> то с типом int вполне часто встречаются грабли, при переносе кода на 64 битные железки.

С ним и более интересные грабли случаются когда шибко умный кодер передает его вооон туда, но оказывается что если caller передаст его функции вот так, отрицательным (а чего, так можно было) то вся дальнейшая математика развалится и оно вообще вон тот массив чудесно дереференснет, только там уже не массив давно, с таким то индексом у него. Вот какого черта вообще везде int тыкать? Так, затыкая очередной vuln, однако.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру