The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

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

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


60. "Релиз ядра Linux 6.2"  +1 +/–
Сообщение от Neon (??), 20-Фев-23, 16:01 
Используемый в ядре тип "char" теперь для всех архитектур по умолчанию объявлен как беззнаковый - странная фигня. Всегда по умолчанию считался знаковым. Грабелек стало мало, решили добавить новые ?
Ответить | Правка | Наверх | Cообщить модератору

67. "Релиз ядра Linux 6.2"  +3 +/–
Сообщение от Максим (??), 20-Фев-23, 16:29 
char - это код символа, зачем ему знак? Если нужен байт со знаком - есть int8_t
Ответить | Правка | Наверх | Cообщить модератору

106. "Релиз ядра Linux 6.2"  +/–
Сообщение от _kp (ok), 20-Фев-23, 18:00 
Знаковость char на разных всегда была платформах разная. Сильно реже и его размер не 8 бит.
Полагаться на то что он точно знаковый, или точно беззаковый - граблестроение!
При вычислениях его нужно явно приводить к нужному типу со знаком или без, или использовать только для строк.

Лучше б добавили опцию со случайным включением/отключением знаковости char. :)

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

166. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноним (99), 20-Фев-23, 21:48 
Вы можете случайно включать опцию -funsigned-char или -fsigned-char
Или написать свой режим для gcc и прислать разработчикам патч.
Ответить | Правка | Наверх | Cообщить модератору

184. "Релиз ядра Linux 6.2"  +/–
Сообщение от _kp (ok), 20-Фев-23, 23:21 
> Вы можете случайно включать опцию -funsigned-char или -fsigned-char
> Или написать свой режим для gcc и прислать разработчикам патч.

Я пишу под разные архитектуры, и моему коду  глубоко фиолетово как реализован тип char, и с какой опцией собирать.
Но сторонний код может иметь различные проблемы из за вероубеждений автора.

В принципе наличие или отсутствие знака у char - результат исторического бардака, и понятие искусственное, не зависящее аппараттно ни от одной платформы.

Одни считали что раз неуказано явно unsigned char, то да будет он знаковым, но с друггй стороны, если это единица текста, на кой чорт ей знак. Далее авторы, котором было лень писать длинно или использовать другой тип, понаплодили непереносимого кода.

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


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

207. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноним (99), 21-Фев-23, 00:06 
Ну вы же сами хотели случайный char, вот можете воспользоваться. Опыт у вас видимо большой
Ответить | Правка | Наверх | Cообщить модератору

237. "Релиз ядра Linux 6.2"  +2 +/–
Сообщение от fuggy (ok), 21-Фев-23, 03:44 
То есть когда создавали Си делали его для кроссплатформенности, чтобы не использовать разный ассемблер. Но сделали типы на разных архитектурах не только разного размера, но и разной знаковости.
Если всё равно приходится учитывать разные размеры типов под разными архитектурами, то где кроссплатформенность? Почему нельзя было сразу сделать нормальные int8, uint8 и тд. А если не учитывать различия архитектур, то при этом ловить ошибки типов.
Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

280. "Релиз ядра Linux 6.2"  +1 +/–
Сообщение от _kp (ok), 21-Фев-23, 11:45 
> То есть когда создавали Си делали его для кроссплатформенности, ...
> почему нельзя было сразу сделать нормальные int8, uint8 и

Так сам язык сразу позволял переопределить типы как угодно.
Типы char, int, long, float.. - это то что поддерживается аппаратно, или дешево реализовать, но зависит от платформы.
Аппаратные типы ведь должны были быть определены по любому. Вот их определили
А остальное волен как хочешь делать.
Или использовать готовый stdint.h

Проблема появилась когда не читавшие документацию считали что платформа под которую они пишут вечна, а базовые типы, якобы, то что нужно использовать везде. Они же типа стандартные.
А то, что "стандартные" они  для одной платформы и конкретного компилятора, проигнорировали.

Замечу, что программисты сразу писавшие под несколько платформ, нечаянно ошибки с типами делали редко.
А вот забивали на старое, или другой ABI, уже целенаправленно, но это другой вопрос.


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

301. "Релиз ядра Linux 6.2"  +/–
Сообщение от fuggy (ok), 21-Фев-23, 14:59 
Так вот и остаётся вопрос. Если есть в языке стандартные типы, да они архитектурно зависимые. Нет не в компиляторе, они стандартные в стандарте языка. Но стандартные типы лучше не использовать, потому что можно выстрелить в колено размером типа. Тогда почему они стандартные? Стандартные же значит, что они должны подходить для большинства, как рекомендуемый способ.
Конечно, если пишешь одноразовое приложение под машину разработчика, тогда нет смысла думать об этом. В остальных случаях так и так придётся использовать stdint.h, и стандартные типы не стандартные получаются.
Ответить | Правка | Наверх | Cообщить модератору

292. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноним (38), 21-Фев-23, 12:56 
Неправильно. Они создавали свой язык насмотревшись на другие языки программирования чтобы писать систему и утилиты не на ассемблере потому что сильно изгибнувшись можно было написать практически такой же быстрый код, но с меньшим числом записей. Гуру ассамблера спокойно читают сишный код понимая какие инструкции это будут. То что он оказался переносимым это уже отдельный эффект потому как требовался компилятор вначале чтобы перенести на целевую архитектуру. Изначально планировалось подсадить всех на свои компы конечно же как Ябло делает нынче.
Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

316. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноньимъ (ok), 21-Фев-23, 23:05 
>То есть когда создавали Си делали его для кроссплатформенности,

Когда создавали Си - делали его ради шутки.
Шутка в итоге оказалась глупая и злая.

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

219. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноним (-), 21-Фев-23, 01:13 
> char - это код символа, зачем ему знак?

Чтоб пятку себе покрасивее простреливать, с заподвыподвертом - сколько народа оперируя на массиве char[] о вон том вообще задумывается?

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

76. "Релиз ядра Linux 6.2"  +4 +/–
Сообщение от Аноним (14), 20-Фев-23, 16:37 
> Всегда по умолчанию считался знаковым

всегда считался зависимым от архитектуры, например на самой распространённой ARM - беззнаковый

> Грабелек стало мало, решили добавить новые ?

по вашему лучше чтобы код с неопределённым поведением оставался в ядре ?

        for (i = 0; i < P4_CNTR_LIMIT; i++) {
          ===>  j = bind->cntr[thread][i];
                if (j != -1 && !test_bit(j, used_mask))
                        return j;
        }

Making this member unsigned will make "j" 255 and fail "j != -1"
comparison.

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

80. "Релиз ядра Linux 6.2"  +1 +/–
Сообщение от Аноним (49), 20-Фев-23, 16:43 
Архитектурно зависимые типы данных это то чем Сишники гордятся. Стандарты это навязчивые копрорастами ценности. Потом вылазят такие кабачки как GNU C, и собственные соскрябанные по сусекам stdint.h и inttypes.h в каждом GNU проекте с последней датой обновления 1999 год.
Ответить | Правка | Наверх | Cообщить модератору

86. "Релиз ядра Linux 6.2"  +2 +/–
Сообщение от Аноним (14), 20-Фев-23, 17:07 
> Потом вылазят такие кабачки как GNU C

в ядре Linux свои фиксированные типы появились задолго до твоего рождения, иди матчасть учи

https://github.com/torvalds/linux/blob/master/tools/include/...

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

142. "Релиз ядра Linux 6.2"  +2 +/–
Сообщение от Аноним (49), 20-Фев-23, 20:01 
> свои фиксированные типы
> свои

В этом и проблема.

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

148. "Релиз ядра Linux 6.2"  +1 +/–
Сообщение от Аноним (14), 20-Фев-23, 20:42 
> В этом и проблема

проблема это когда железо недокументированное, а какие проблемы с пониманием u8, s8, u16, s16, u32, s32, u64, s64 ?

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

160. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноним (99), 20-Фев-23, 21:31 
А как надо?
Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

220. "Релиз ядра Linux 6.2"  +1 +/–
Сообщение от Аноним (-), 21-Фев-23, 01:21 
> А как надо?

#include <stdint.h>
#include <stdbool.h>

Как-то так. И да, UB sux. Например на нормальном буле из C99 - избегается ряд UB. А когда вы просите именно uint8_t то можно ожидать именно это. А из чего кастомный u8 сделан - это такой себе отдельный вопрос. И как минимум заставляет тратить время чтобы изучить этот вопрос и понять границы применимости.

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

134. "Релиз ядра Linux 6.2"  +1 +/–
Сообщение от Аноним (134), 20-Фев-23, 19:27 
Так, плюсы ты перечислил, а минусы какие?
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

161. "Релиз ядра Linux 6.2"  +1 +/–
Сообщение от Аноним (99), 20-Фев-23, 21:37 
Никаких
Ответить | Правка | Наверх | Cообщить модератору

79. "Релиз ядра Linux 6.2"  +7 +/–
Сообщение от Аноним (49), 20-Фев-23, 16:38 
Если вы садомазо и используете char вместо int8_t, а теперь жалуетесь что отрицательные значения выдают результат 255 минус значение + 1, то вам нужно сдать анализы и как можно скорее.
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

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ообщить модератору

211. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноним (211), 21-Фев-23, 00:25 
Отрицательный signed не может выдать значение 255 если что.
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

223. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноним (-), 21-Фев-23, 01:39 
> Отрицательный signed не может выдать значение 255 если что.

Зато его можно загнать индексом массива. И при случае получить очень интересный дереференс, когда код вида 

void abc(int def)
{
int abc[20];
...
if (abc[def] > 0) ...  // interesting mem access if def < 0 
}

Еще можно двигать на отрицательное число биты. Тоже годная развлекуха. Не то чтобы совсем не получится - но UB жесточайший.

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

118. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноним (99), 20-Фев-23, 18:40 
Где в стандарте С написано что char должен быть беззаконным?
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

127. "Релиз ядра Linux 6.2"  +1 +/–
Сообщение от Советский инженер (?), 20-Фев-23, 18:58 
где тьі в ядре увидел стандартньій С?
Ответить | Правка | Наверх | Cообщить модератору

188. "Релиз ядра Linux 6.2"  +/–
Сообщение от _kp (ok), 20-Фев-23, 23:26 
> Где в стандарте С написано что char должен быть беззаконным?

В стандарте прямо сказано, что char может быть каким угодно, а размер int не меньше размера char....

В сделано согласно стандарту.

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

121. "Релиз ядра Linux 6.2"  +1 +/–
Сообщение от Аноним (99), 20-Фев-23, 18:47 
>Грабелек стало мало, решили добавить новые ?

Само собой необразованные современные якобы разработчики ядра, не способны понять последствия их решений.

Единственное что не понятно мне, веб-макаке, что плохого в беззнаковых типах char, ведь для них определено переполнение. А для типов со знаком переполнение вызывает неопределенное поведение.
В смузи-языках типа java тип char беззнаковый.

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

192. "Релиз ядра Linux 6.2"  –1 +/–
Сообщение от _kp (ok), 20-Фев-23, 23:39 
Де-факто давно и так в основном компилируют с  типом char, как беззнаковым.
Новое требование только устанавливает явные правила для сборки ядра, и облегчения сопровожления кода на назных платформах.

Так что, для большинства не поменялось ничего.


> что плохого в беззнаковых типах char,
> ведь для них определено переполнение.

В низкоуровневом коде обработка переполнения деляется явно, а не по исключениям и т.п.

> А для типов со знаком переполнение  вызывает неопределенное поведение.

Это исскуственная догма.
При ручной проверке в Си, как и в ассемблере проверкой по флагам процессора, задаётся любое поведение. Или игнорируется переполнение. Или учитывается иначе


> В смузи-языках типа java тип char беззнаковый.

Ещё бы в пределах одной платформы бардак развели. Одна платформа - одно соглашение о  типах. Любое, но единообразное.


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

206. "Релиз ядра Linux 6.2"  –2 +/–
Сообщение от Аноним (99), 21-Фев-23, 00:03 
Уточните, пожалуйста:
Что такое явная обработка переполнения, что такое неявная?
О каких исключениях идёт в Си?
Что за искусственная догма? Неопределенное поведение при переполнении у знаковых типов задано стандартом.
Какой у вас опыт программирования на Си?
Ответить | Правка | Наверх | Cообщить модератору

168. "Релиз ядра Linux 6.2"  +/–
Сообщение от Аноним (168), 20-Фев-23, 22:02 
> тип "char"

Когда тебе нужен не "символ", а число - пиши явно "signed char" или "unsigned char" и будет счастье!

На самом деле всегда так было, просто многие не задумывались об этом...

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

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

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




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

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