Rust обогнал Сишечку по скорости распаковки

все UB сишки, это «UB» железки на которой крутится код

Даже близко нет. Сходи список UB почитай.

Да это-то ладно. В сишечке незакрытые кавычки – UB. Да, так написано в стандарте. Я всё хочу чтобы сишные гуру объяснили мне смысл этого вот и почему это UB, а не гарантированная ошибка синтаксиса.

Цитата:

An unmatched ’ or " character is encountered on a logical source line during tokenization

ибо парсинг не всегда ll(1) дк(1) и прочий фан

кой какие реализации успели просто строки поэтому не факт что отсутствие(а точнее не обнаруженость как того суслика которого не видно а он есть) -

вот такая загагулина

«просто не рассчитывай» что ошибка в синтаксисе будет словленна до отправки посылки из места с лозунгом «наша цель коммунизм»

INT_MAX + 1 это UB. Никаких прерываний и запретов со стороны железа нет.

еще раз говорю. заниматься сишечкой не зная ассемблера, это все равно что резать скальпелем не зная анатомии.

при переполнении процессор выставляет флаг переполнения и этот флаг можно учитывать при следующей арифметической команде или проверить этот флаг.

таким образом делается длинная арифметика, например. или проверятся факт переполнения.

то есть переполнение это не UB!, это нормальная работа железа, например при длинной арифметике.

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

то есть переполнение это не UB!, это нормальная работа железа

Ну так а я о чём говорю? Железу нормально, а по стандарту Си это UB.

этот флаг можно учитывать при следующей арифметической команде или проверить этот флаг

И при чём тут Си?

при переполнении процессор выставляет флаг переполнения

то есть переполнение это не UB!, это нормальная работа железа, например при длинной арифметике.

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

Впрочем, в C11 (annex L) многие UB включая переполнение перенесли в категорию bounded undefined behavior. То есть UB для которого разработчики компилятора должны гарантировать отсутствие записи за пределы выделенной памяти (should they choose to accept the mission).

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

а есть и такие? флаг переноса делается для длинной арифметики. и индикации переполнения. процессор без такого флага выглядит странно. видимо экономили на вентилях лет 50 назад.

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

В си только знаковое переполнения является неопределённым поведением. Беззнаковое вполне определено: UINT_MAX + 1 == 0.

Флаги переноса тут не причём. Знаковое переполнение будет себя вести по-разному на one’s complement и two’s complement платформах, поэтому в Си такая залупа. Другой вопрос, что one’s complement не осталось в принципе, это говно давно сдохло. Поэтому эта срань с UB в Си не имеет смысла и нужна только для страданий ради страданий.

ибо парсинг не всегда ll(1) дк(1) и прочий фан

А зачем это в Си?

Знаковое переполнение будет себя вести по-разному на one’s complement и two’s complement платформах

Для этого бы хватило implementation defined. Но пытались охватить вообще всё что возможно с сохранением возможности оптимизаций.

Для этого бы хватило implementation defined.

Для очень многих вещей хватило бы implementation defined, но наркоманы, писавшие стандарт, решили всем поднасрать. И не то чтобы они останавливались, UB в Си продолжают добавлять, дабы нам всем не было скучно.

дык

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

а изначально Си это буквально переносимый асм для реализаций остальных инструментов Ахо awk и прочие компиляторы картинок

вообще Сяшка победила(а для эмбедивщины это выглядит вообще парадоксально) - что и ся изначально выделенно что есть сервисы машины - и поэтому многие(не все)ub что бы не ограничивать количество хостов годных без рантайма - и что есть сервесы «рантайма» который обычно воспринимается как операционная система :)

парадокс Си как таковых сам язык был реально беднее и кривее но благо юниксу стал лингво-франкой

по хорошему в Си как и JS тока транспилинг :)

ps https://en.wikipedia.org/wiki/Portable_C_Compiler#Features

PSS https://en.wikipedia.org/wiki/Stephen_C._Johnson#Bell_Labs_and_AT&T

PSSS https://en.wikipedia.org/wiki/Yacc#History

в целом

https://en.wikipedia.org/wiki/History_of_Programming_Languages_(conference)

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

Почему нет? При отсутствии парных скобок, кавычек и прочего должна быть выброшена ошибка синтаксиса. Думаешь, никто бы не справился? Авторы сишных цомпилеров настолько беспомощны, что даже этого не могут?

а изначально Си это буквально переносимый асм для реализаций остальных инструментов Ахо awk и прочие компиляторы картинок

К асму Си был близок только на PDP-11. На любом другом компьютери в Си от асма нет ничего.

парадокс Си как таковых сам язык был реально беднее и кривее но благо юниксу стал лингво-франкой

Учитывая, что юникс благополучно сдох – линукс к юниксу отношение имеет примерно такое же, как венда – мы можем только надеяться, что сишечка последует его примеру.

На любом другом компьютери в Си от асма нет ничего.

а если найду?

int x = (*ptr)[i] - такая штука пишется на интеле одной командой. думаешь просто так к поинтеру индекс прицепили, системный ты теоретег. это мода адресации - база плюс индекс в регистрах и константа - размер элемента. вычисляется аппартно как base_reg + index_reg * size.

Потому что надо было нормальные типографические кавычки-ёлочки или лапки юзать, но в силу ограниченности tty model 33 решили один и тот же символ для начала и конца строки использовать.

а есть и такие?

RISC-V.

А сколько микро-операций на такое уйдёт?

А сколько микро-операций на такое уйдёт?

меньше чем делать то же самое несколькими командами.

int x = (*ptr)[i] - такая штука пишется на интеле одной командой

let x: int = array[i]; такая штука пишется на интеле одной командой. Rust близок к ассемблеру.

Мне нравится твоя повёрнутость на Си. Ты не знаешь этого языка, но у тебя офигенное мнение о нём.

Мне нравится твоя повёрнутость на Си. Ты не знаешь этого языка, но у тебя офигенное мнение о нём.

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

Возможно, что и так. Но Rust уже в ядре и его там будет только больше, а тебе жопу рвёт. Разве это не прекрасно?

Но Rust уже в ядре и его там будет только больше

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

а вот в ядре его и в лупу не разглядишь.

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

Там выше написали подробно про проблему с твоей методологией.

Там выше написали подробно про проблему с твоей методологией.

жалкие отмазки. достаточно просто посмотреть списки и видно, что там про конкретно про руст сплошь и подряд, а не случайное совпадение с чем-то там.

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

жалкие отмазки. достаточно просто посмотреть списки и видно, что там про конкретно про руст сплошь и подряд, а не случайное совпадение с чем-то там.

Это-то да, всё так. Навскидку, 80% поиска про Rust там имеют отношение к Rust. Проблема в том, что это же утверждение неверно для C++. Большая часть уязвимостей в коде на C++ в твой поиск не попала.

Всё, что ты показал, это что авторы кода на Rust любят пихать слово Rust в название. Вот и всё.

с++, на котором пишет большинство разумных программистов

Толсто же!

Толсто же!

правда толстой не бывает.

Всё, что ты показал, это что авторы кода на Rust любят пихать слово Rust в название.

причем тут авторы? уязвимости описывали не авторы, а какие-то независимые копатели уязвимостей. ровно как и про случаи с++.

видимо руст так всех достал, что даже копатели немедля указывают его в описании того, что нашли.

выбирать по собственной воле плюсы как язык имплементации это заявка на гурманство ортогональное разумности

ибо

С++ хорошь как компромис во восход wintel 80-90ых когда охота по внешности летающий шар смолтока со всяким 3d gui и шоб летало как сяшка( просто асм не катил ибо хоть wintel уже был мажорирующией частью но не было гарантий что это на 20-30 лет - да и синтаксис у просто асмов излишне примитивен)

жаль что моден rust а не zig :)

плюсы это франкеншнейн и в этом смысле жаль что Страуструп настолько крут как менеджер проекта

при этом : Alexander Stepanov Introduces Bjarne Stroustrup

т.е достаточно возможности до битов и качественная перегрузка синтаксиса

во втором в С++ адиизраиль