The OpenNET Project / Index page

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

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


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

Оглавление

Выпуск Rust 1.79. Создан консорциум для разработки высоконадёжных систем на Rust, opennews (??), 13-Июн-24, (0) [смотреть все]

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


55. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (55), 14-Июн-24, 05:59 
> Страшный с++.
> Который вытеснил сишку практически из всех областей разработки, даже из embedded.

Да вот вся фирменная идиотия сей - на месте. Типа int хрензнает какого размера и прочих integer promition с совершенно отшиблеными правилами вида "попробуй угадать что сделает клмпилер".

Хотя при сильном желании на плюсах можно даже сделать подобие сабжа, конечно. На минималках даже из сишки немного можно. Только криво.

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

119. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (-), 14-Июн-24, 11:15 
> Да вот вся фирменная идиотия сей - на месте.

Да, к сожалению. Это цена поддержки обратной совместимости.
Но лучше хорошее + чуть сишной убогости, чем одна только убогость.

> Хотя при сильном желании на плюсах можно даже сделать подобие сабжа, конечно. На минималках даже из сишки немного можно. Только криво.

Только это будут уже не плюсы и не сишка. А какой-то кадавр, над которым поиздевался хирург mad-doc.

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

261. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (261), 14-Июн-24, 18:21 
> Типа int хрензнает какого размера

Так это специально. Зависимый от железа int - самый быстрый.

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

262. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +1 +/–
Сообщение от Аноним (261), 14-Июн-24, 18:21 
И int фиксированного размера давно уже есть и в C, и в C++.
Ответить | Правка | Наверх | Cообщить модератору

310. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (-), 15-Июн-24, 00:22 
> И int фиксированного размера давно уже есть и в C, и в C++.

Спасибо Капитан Очевидность! Вы дали фееричную лекцию - практикующему сишнику и немного плюсовику как раз.

К сожалению это все было сделано комитетом полудурков максимально через ж"пу.
1) В препроцессоре тоже есть вычисления. И конечно без нормальных типов данных, чтобы было не очень скучно. Забавно же когда все константы и предвычисления препроцессором - implementation defined?!
2) 1, 1U, 1UL и 1ULL это 4 довольно разные вещи... и сколько там де факто в граммах^W битах в том или ином случае окажется - довольно интересный вопрос.
3) Все это лезет в практически всех математических операциях, чтобы не было скучно, а с правил integer promition слетят с катушек даже ящеры с другой планеты, пожалуй.
4) До C23 (и C++ рядом) signed int overflow/underflow - махровейшее UB. Например потому что формат хранения signed int - ну, их несколько разных. В 23 это все же заманало и зафорсили two's complement. Но UB все равно формально не сняли. Бег по граблям с препятствиями.
5) А ваш код переживает -Wconversion без варнингов? Это такой миноискатель показывающий где вон те грабли (могли) быть.
6) Можно юзать signed int как индекс массивов. При том отрицательный индекс не то чтобы сильно редко случается в real world коде. С понятным результатом.
7) enum в сях да и плюсах довольно бесполезная хрень, даже если что-то typedef'нуть в него - это никак не энфорсится и не проверяется. Даже когда можно было.
8) Аннотации типа foo(array[10]) просто отбрасывают аннотацию [10] и вот так сразу - никто ничего не проверяет.
9) Бывают всякие builtin типа add_overflow, но они нестандартные.

Очень сильно сбоку - на сях и особенно плюсах можно немного абстрагировать некоторые вещи, но вообще-то так должно было быть по дефолту. И в хрусте смогли по крайней мере нормальные типы данных, когда не надо гадать сколько битов реально вот тут было - и нагнется ли такая математика - и если да то как именно это будет.

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

346. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от тыквенное латте (?), 15-Июн-24, 07:00 
юзер234, ты от девопс экспертизы перешел на кодинг? хоспате, пощади.
Ответить | Правка | Наверх | Cообщить модератору

359. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (-), 15-Июн-24, 08:31 
> юзер234, ты от девопс экспертизы перешел на кодинг? хоспате, пощади.

Я умел програмить чуть менее чем всегда. Так что уж прости, лаптэ. А по делу сказать нечего? Грабли сишки я получше вашего обпрыгал. И почему-то не горю желанием прыгать по граблям до гроба.

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

383. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Ivan_83 (ok), 15-Июн-24, 13:57 
Вы плохо практикующий, потому что:
- С это не язык по какой то там спеке, это язык про железо, поэтому какойнить int не зазорно быть аппаратно зависимым типом
- достаточно пару раз наступить на грабли чтобы запомнить и больше не наступать, это называется обучаемость
- про енумы - в сях вообще ничего не энфорсится, потому что это не язык БДСМщиков
- отрицательные индексы для массивов тоже возможны, иногда так задумано, хотя я не разделяю таких методов
Ответить | Правка | К родителю #310 | Наверх | Cообщить модератору

404. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (-), 15-Июн-24, 21:33 
> Вы плохо практикующий, потому что:

Хотите об этом поговорить? Окей, "пошло веселье!" (c) джеди.

> - С это не язык по какой то там спеке, это язык
> про железо, поэтому какойнить int не зазорно быть аппаратно зависимым типом

Вообще-то в случае железа - я как раз хочу железобетонно знать именно конкретный размер операции, а желательно еще и понимать атомарность "от и до". Не угадать с размером операции чревато, ибо регистры железа вполне конкретного размера и большой вопрос что будет если промазать с этим, "depends". А факап с атомарным доступом ведет к глюкам раз в год, которые вообще хрен отдебажишь (впрочем на сравнимые грабли можно и с многопоточностью встать).

> - достаточно пару раз наступить на грабли чтобы запомнить и больше не
> наступать, это называется обучаемость

Судя по числу вулнов, сбоев и прочих факапов математики которые я в таком коде "от дидов" конопатил, с этим были, есть и будут проблемы. Если грабли не раскладывать - не придется прокачивать скилл в бинтовании лбов. Ну вот реально - нафиг надо тратить время на борьбу с проблемой которой быть не должно с самого начала. И да, если бы стандарт делал я, я бы переделал работу с integer'ами до конкретных размеров, как в хрусте, по всей площади. И в препроцессоре, и в математике, и в константах, и проч. С более другими правилами.

> - про енумы - в сях вообще ничего не энфорсится, потому что это не язык БДСМщиков

БДСМ это как раз пытаться поймать баг где по ошибке вкатили левое значение - например опечатавшись. И enum мог бы заметить что ну вот явный левак дали. Ан нет. Чисто декоративная хреновина, существующая неизвестно зачем. Почтальон печкин: задекларить намерения кодера можно, но это никого ни к чему не обязывает.

Более того - даже тип к которому enum будет де-факто приведен и грабли на этом пути это очень сильно отдельный топик. И самое печальное что там нет хорошего, простого, однозначного ответа "а что это на самом деле будет". Это хреновый стандарт, вот хоть как.

> - отрицательные индексы для массивов тоже возможны, иногда так задумано, хотя я
> не разделяю таких методов

На мой вкус именно в массивы это не должно катить. То что это де факто decays to pointer - окей, одна из причин по которым в сях проблемы с статическим анализом. А падающая в рантайме фирвара, бутлоадер или ядро - немного не то чего мы хотели от системщины, уж пардон.

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

422. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Ivan_83 (ok), 16-Июн-24, 06:17 
Про енум согласен.

В остальном ещё раз подумайте и поймите, что это язык для работы с железом на низком уровне прежде всего, а уже потом всё остальное.
Поэтому инты - это любая хрень со знаком размером с регистр проца, а если надо что то конкретного размера то отдельно завезли uintXX_t, intXX_t и прочее.
Про оверфлоу при вычислении примерно так же: обычно на это пофиг, потому что системный код простой и примитивный, там и так понятно что до MAX_INT оно никогда до досчитает, потому проверками никто не заморачивается, ради скорости и простоты.
То что ими не заморачиваются там где рассчёты и где оно может случится - это отдельная история.

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

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

466. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (-), 17-Июн-24, 08:02 
> Про енум согласен.

Да там не только в нем проблема. Но enum - просто такой характерный пример когда вроде ну все сделали - и зачем-то пролюбили пойнт сделаного. А зачем делали тогда? Чисто для галочки что, вот, фича есть?

> В остальном ещё раз подумайте и поймите, что это язык для работы
> с железом на низком уровне прежде всего, а уже потом всё остальное.

Я по моему очень понятно обрисовал что я на самом деле хочу при вот именно работе с железом. А вот что я совершенно точно при этом не хочу - дурацкие првила integer promotion, UB и тому подобное веселье. Ибо железо так то разное бывает. Как тебе сбой в фирваре крутящей вон тот двигун? Или рулящей вон тем опасным процессом? Ну очень круто, да? И в этом месте последнее что я хочу видеть - это "size_t" хрен знает какого рамера, непонятки "что будет если?" и тому подобные вещи, типа игнора аннотации вида array[10] до "decays to pointer" и даже очевидный out of bounds - не ловится сколь-нибудь регламентировано и штатно.

> Поэтому инты - это любая хрень со знаком размером с регистр проца,
> а если надо что то конкретного размера то отдельно завезли uintXX_t, intXX_t и прочее.

Как я уже сказал, полудурков из ISO не хватило чтобы сделать это нормально. Поэтому в препроцессоре, константах, enum и прочем integer promotion можно знатно попрыгать по граблищам, которым к тому же топор на рукоять одели для лулзов.

Да, даже просто написать "+ 1" может сделать немного не то что програмер подразумевал, очень контринтуитивно запромотив тип. Enum'а это тоже касается. И булеаны появились в том числе и поэтому. А чтоб вы не скучали - в C23 их вынесли, #include <trollface.h> однако :)

> Про оверфлоу при вычислении примерно так же: обычно на это пофиг, потому
> что системный код простой и примитивный, там и так понятно что
> до MAX_INT оно никогда до досчитает,

Ага, вон там господа тоже так думали. В результате код разбора пакета вон там радостно делает отрицательный индекс, условие вообще не срабатывает граблина очень долго шарахается по левой памяти. Все как диды любят! Ну, подумаешь, ремотным пакетом по воздуху можно системе череп прострелить, никого не спрашивая, мелочи какие.

> ради скорости и простоты.

Я думаю что по состоянию на сейчас пора пересмотреть эту практику и явно аннотировать критичный к перфомансу код как таковой. Иначе - получается фигня как выше, и это очень сомнительная услуга человечеству. Да и большую часть проверок компилер так то может выпилить оптимизером - на самом деле там прувер мама не горюй у современных компилеров, он это для оптимизаций делает, но вон там - Торвальдс крыл gcc за удаленные проверки null, где с этим в компилере малость перестарались даже :)

> То что ими не заморачиваются там где рассчёты и где оно может
> случится - это отдельная история.

Меня как-то напрягает что вон той системке можно радиопакетом череп вынести просто подогнав значения чтобы алго посчитало не то что там себе диды вообразили, сорян. Так быть не должно.

> Ну и раз вы хотите быть уверенны во всём, вы же должны
> понимать что ваш код просто обязан работать только на платформах где
> память с ECC, иначе никакой гарантии того что вы записали 22
> и прочитаете 22 просто нет.

FYI у микроконтроллеров бывает и оператива с parity/ECC, и флеха с ней же. И на десктопе у меня таки тоже ECC. А вы можете глюкать и прыгать по граблям если хотите. И файлуху без чексум можно юзать.

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

307. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (-), 15-Июн-24, 00:02 
>> Типа int хрензнает какого размера
> Так это специально. Зависимый от железа int - самый быстрый.

Поэтому взяв допустим ардуину, и вкатив там ключом компилера вот именно 16-битный int (да, так на 8 бит платформе будет куда быстрее) - можно будет быстренько узнать почем сегодня фунт лиха.

С одной стороны это - абсолютно по стандарту. С другой - 95% кода на этом глобусе, разумеется, не ожидает столь фееричной подляны. Кто ж эти ваши стандарты еще и читает то, от и до?!

И в результате это не только самый быстрый - но и самый грабледром.

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

280. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Ivan_83 (ok), 14-Июн-24, 20:41 
Если вы не в курсе, то часто реально пофиг какого там размера этот самый int, потому что его пихают чтобы посчитать от 0 до 10.
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

360. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (-), 15-Июн-24, 08:37 
> Если вы не в курсе, то часто реально пофиг какого там размера
> этот самый int, потому что его пихают чтобы посчитать от 0 до 10.

Зато в случае когда там было поболее чем 10 - становится очень сильно не пофиг. Когда код глючит, разваливается, непортабельный, а помахав стандартом - забыли с ним комплайнс обеспечить. А зачем тогда стандарт был, блин? И зачем он написан как написан?

А в случае всяких там индексов и чего там еще - самое то, в паре с integer promition, чтобы прострелить себе череп с заподвыподвертом, в прыжке, держа пистолет левой ногой. Даже не заметив этого, ибо -Wconversion какой - это таки хардкор и далеко не каждый рискнет сие вкатить на свой код.

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

384. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Ivan_83 (ok), 15-Июн-24, 14:02 
Насколько по более?)
Я везде у себя юзаю size_t для размеров и индексов, но та же луа почти целиком на int и ничего.
Более того там и отрицательные значения для индексов используются активно и это нигде не мешает.

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

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

405. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (-), 15-Июн-24, 21:47 
> Насколько по более?)

Ага, вы кажется начинаете о чем-то догадываться. Большая часть кода на этом глобусе железно уверено что в int лезет что-то уровня 2^31-1. И вон там, в примере с авркой, если мы еще и удумаем реально поюзать даденое стандартом право сделать платформе удобно, вкатив int сподручный ей, 16 битов, ибо по стандарту так можно было - мы гуано откушаем на большей части кода.

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

Угу, теперь попробуй фирмварь так написать. А потом перенести скажем работу с конкретной железкой на пару других платформ. А допустим в лине - драйверы цепляют свои железки - на довольно разном cpu core, и если они будут на такие вещи уповать.... Ну вот нет, от того что линух работал только на i386 торвальц ушел, и почему портабельность хорошо - понял. На память об этом у нас 1 набор дров под разные платформы работает. Ведь скопипастить IP-блок можно к любому процессорному ядру, равно как и PCI какой к нему пристроить, etc.

> Более того там и отрицательные значения для индексов используются активно и это
> нигде не мешает.

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

> И не забывайте что С был для работы с реальным железом, очень разным,

И я работаю с реальным железом побольше вашего, достаточно для того чтобы не нести ересь про size_t который так то как раз об обратном. Не, при работе с вот именно железом вы совершенно точно не хотите никакое size_t, да и при работе с сетевыми протоколами или форматами файлов вы тоже ему будете зело не рады, ибо хрен его знает когда это развалится.

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

Угу, и в результате получился масс-глюкодром. Который разгребать еще праправнуки будут.

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

Для асма тем более непростительно то что оно с типами и integer promition вытворяет. Впрочем это даже и в апликушных вещах может все нагнуть при желании пульнуть что-то по сети или прочитать файл одинаково на разных платформах.

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

423. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Ivan_83 (ok), 16-Июн-24, 06:25 
Большая часть кода с int которую я видел за последнее время (lua, return error code в линухе/бсд) легко могла бы уложится в 16 бит, а может даже и 8.


size_t - это для размера куска памяти на конкретной архитектуре где собран код.
В форматы его понятное дело не пихают ибо получится плохо переносимо.
Но тот же memset(), memcpy(), strlen() - это уже давно с size_t, везде.

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

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

467. "Выпуск Rust 1.79. Создан консорциум для разработки высоконад..."  +/–
Сообщение от Аноним (467), 17-Июн-24, 08:16 
> Большая часть кода с int которую я видел за последнее время (lua,
> return error code в линухе/бсд) легко могла бы уложится в 16
> бит, а может даже и 8.

Проблема в том что "меньшей" части вполне хватит чтобы огрести дохрена неочевидных багов. Реально кода который compliant с столь дурацким стандартом - не больно дофига.

> size_t - это для размера куска памяти на конкретной архитектуре где собран код.

Опять же - если мы например с хардварным регистром размером 32 бита работаем, этот IP блок uncore, внезапно, могли пришить к совершенно разным cpu core. А идея скопипастить обвес uncore - ну вот вообще ничему не противоречит. И потом - и с дравером ЭТО ЖЕ сделать, чем какие-нибудь линуксоиды хуже VHDLщиков всяких? Они о вон том - догадываются.

...и в этом месте мы начнем догадываться, что для вот именно работы с железом size_t как раз таки вообще совсем не оно. У железок бывают вполне конкретные требования по размеру доступа за раз, выраваниванию и проч. А если попробовать что-то иное - грабля по морде даст так что мало не покажется. А оно может тупо не уметь иные варианты доступов в тот регион, для упрощения и ускорения железа, например.

> В форматы его понятное дело не пихают ибо получится плохо переносимо.
> Но тот же memset(), memcpy(), strlen() - это уже давно с size_t, везде.

И за это тоже воздается глупыми багами на ровном месте...

> В асме код тоже далеко не всегда с проверками переполнения, потому что
> очевидно часто оно не случится никогда.

Есть довольно большая разница между доказуемыми вещами, и "наобум напрогали так". В коде от дидов много второго. И на краевых условиях это добро сыпется только в путь. И вот ЭТО как раз несколько заманало.

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

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

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




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

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