что ещё можно ответить не адеквату?

царь говорит: «кококо», я отвечаю :«кококо & 1 == 0»

жобс, конкретно для тебя - нигде. специально для тебя компиляторам разрешено генерить код читающий /dev/random вместо того что написано в файле при упоминании int в исходниках.

спасибо, учител!

и ты чо, серьезно не знаешь, как это переписать так, чтобы не было UB?

это не UB, это баг. такая «оптимизация» недопустима.

Могу поставить 20 баксов что это баг у тебя в программе а не в компиляторе.

Добавь при компиляции флаги -O1 -g -fsanitize=undefined и запусти. Тебе компилятор сам подскажет где у тебя ошибка.

Ты читал и ты впитал, но при этом можешь ли ты мне что-то ответить? Нет. И не важно что ты там впитывал, либо не впитывал. Что ты мне будешь ретранслировать - это всё так же не важно.

Я не делаю ошибок автора - я не пытаюсь взывать к вашим характеристикам, к характеристикам авторов компилятора, к правильности/неправильности ваших поверий. Мне неважно кто и чем руководствовался. Это меня абсолютно не интересует.

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

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

я переписал уже. мой поинт в том, что не может сразу за &8191 быть отрицательное число. никак. ну разве что в жаве.

во-первых флаги я поставить тоже не могу ибо сатанинская самопальная система сборки. во-вторых, да не может быть число с обнуленными битами выше 12го отрицательным.

Ты читал и ты впитал, но при этом можешь ли ты мне что-то ответить?

Могу, но мне это было бы скучно, а скучную работу я делаю только за деньги. Увы.

У меня есть базовые понятия

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

Кривляние — плохой ответ. Ты не хочешь признавать, что обосрался, вот и юлишь. В этом ничего страшного нет же.

совершенно не знаю, что возразить господину разработчику gcc.

не может сразу за &8191 быть отрицательное число. никак. ну разве что в жаве.

Как раз в джаве не может, в расте не может, и в go не может. Потому что в этих языках нет UB.

А вот в С и в C++ может если у тебя где-то рядом подкрался UB. Как говорится оно может даже диск тебе отформатировать, и котенка утопить.

в джаве не может, в расте не может, и в go не может. Потому что в этих языках нет UB.

O RLY? https://github.com/rust-lang/rust/issues/1877

Feb 21, 2012

SRSLY ?

я очень извиняюсь, а сдвигами влево/вправо биты нельзя почистить? Вряд ли компилятор будет сопротивляться двигать биты, даже если он считает это UB. Два сдвига в регистре должны быть быстрее одного AND в памяти. Вроде.

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

srly

We decided that this is not worth fixing out of performance concerns

Могу, но мне это было бы скучно, а скучную работу я делаю только за деньги. Увы.

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

А по поводу твоей потуги. Никого не волнует что ты там болтаешь - если опровержения нет - ты проиграл.

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

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

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

я очень извиняюсь, а сдвигами влево/вправо биты нельзя почистить? Вряд ли компилятор будет сопротивляться двигать биты, даже если он считает это UB.

Среди компиляторов популярен следующий ход рассуждений:
1. В этом участке кода неизбежен UB;
2. Программист написал на 100% корректную программу;
3. Из пунктов 1 и 2 следует, что данный участок кода недосягаем во время работы программы. То есть этот участок кода можно не компилировать даже, а все if-ы, которые могли бы привести control flow в этот участок кода, гарантированно получают на вход false (так что во время работы программы можно не тратить время на вычисление условий if-ов).

Еще раз повторю, это было сказано давно и неправда, к версии 1.0 они поменяли undefined behavior на unspecified result.

Пока ты не выкатишь пруфцов обратного - твои потуги будут стоить ноль.

Соль в том, что передо мной не стоит задачи в чем-либо тебя убедить, или что-либо тебе объяснить. Хочешь жить в своем манямирке — да пожалуйста, у меня абсолютно нет мотивации тебя оттуда вытаскивать. Шанс тебе был даден, и бремя того, как ты им распорядишься, лежит исключительно на твоей совести

к версии 1.0 они поменяли undefined behavior на unspecified result

О да, давайте теперь жонглировать словами 🦆.

Ого, какую древность раскопали. Сейчас это работает так: https://play.rust-lang.org/?gist=fdd7ffd6a683bb584cbb98180b759ca1&version...

опенсорц же, сделай пул-риквест в ллвм с этой оптимизацией ;)

давайте теперь жонглировать словами

Если ты не видишь разницы, то ты не умнее автора этой темы.

«Уже 10 лет я считаю спички в коробках с вашей фабрики. Их то 50, то 51, то 49, а иногда и 48. Вы что там сумасшедшие все что ли?» Фишка в том, что вы думаете о существовании некоей правильной неоптимизированной программы и оптимизатора, который улучшает эту программу, не влияя на результат. Возможно, когда-то так и было, вроде как даже стандарт 98го года определял, что корректно скомпилированная программа обязана была работать с volatile-переменныеми и вызывать внешние функции в том порядке, как это в коде. Но сейчас это время прошло. Для отражения проблем с memory ordering и для того, чтоб оптимизация не отваливалась решили предполагать, что UB тупо не будет и на случаи с UB можно забить. В случае отсутствия переполнения компилятор посчитал, что ваше И излишне, вот и выкинул эту операцию нафиг. Джависты тут не при чём

Так оставь только shift by variable.

Хотя я не прав, они после этого еще обновили RFC, теперь вообще все четко и не докопаешься

Shift operations (<<, >>) on a value of with N can be passed a shift value >= N. It is unclear what behaviour should result from this, so the shift value is unconditionally masked to be modulo N to ensure that the argument is always in range.

Откуда тогда паника в примере выше?

есть условное деление на undefined (после этого весь код в undefined-скопе можно считать невалидным - в отдельных случаях вообще всю программу), unspecified (конкретный компилятор может выбрать, как он себя поведет - но программа не обязательно должна стать невалидной, обычно там разумное решение, но это решение не является контрактом для прикладного программиста), и implementation-defined (конкретный компилятор выибрает способ и документирует этот способ явным способом). Так что разница между UdB и UsB прямо радикальная. Собственно, топикстартер и хочет чтобы везде было usb вместо udb

Никто не ломает «неправильный» код, который является частью исторически сложившихся идиом.

if (this == NULL) таки поломали.

оптимизации не могут нарушать логику программы.

Могут.

uint32_t* addr = 0x20000008;
*addr = 0x11223344;
*addr = 0x11223344;
*addr = 0x11223344;
*addr = 0x11223344;
*addr = 0x11223344;

И компилятор, если ему не сказать явно volatile, сломает логику программы, по твоему утверждению.

Попустись.

Млять, ну до чего же эпично!
Ой, чую тема взлетает. Самого Царя с пары-тройки ответов расколбасило в пух и прах.
Иду за новой порцией попкорна.

Лол :-) Мне вот интересно :-) Сколько тебе по-настоящему лет? :-) Ведёшь себя как пацан :-) Представляешь, «сам царь» возмутился :-) Лол :-) Вот эт да! :-) Надо срочно в блоге у себя написать про это :-)

В каком примере?

Вы просто не умеете его готовить: https://play.rust-lang.org/?gist=f09abbf8aceb9ae9567d604ecb7afd21&version...

Только Release поставьте.

Могу, но мне это было бы скучно, а скучную работу я делаю только за деньги. Увы.

Ахаха :-) Могу, но за деньги :-) Не сейчас, товарищи :-) Лол :-)

Соль в том, что передо мной не стоит задачи в чем-либо тебя убедить, или что-либо тебе объяснить.

Типичная манипуляция уровня «табуретка».

Для аудитории поясню. Каждый понимает, что обязанность доказательств лежит на утверждающей стороне. В данном случае персонаж, пользуясь слабостью аудитории, пытается выдать за утверждающего меня. Всё это базируется на попытки убрать со своей стороны какие-то утверждения( это я разберу ниже), а моё требование обоснований он заменяет путём враньё на требования «объяснить/убедить».

По поводу утверждений. Изначально персонаж не спорил со мною - он просто косвенно намекнул на то, что я неправ. Это балабольство он не обязан обосновывать - он бы просто слился. Естественно он никогда мне не скажет, что я не прав, либо что-то типа того - он тут же обделается, как обделался сейчас.

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

Далее, видя жопу, табуретка, пытается слиться на тему первую, в рамках которой он ничего не утверждал. И именно манипуляция и заключается в этом - его просили обосновать не за онтоп, а за его «я могу, но не хочу».

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

В данном случае помножить на ноль табуретку я могу простым вопросом «я прав?». И тут у табуретки два варианта - «нет», а далее «я могу, но не хочу», что эквивалентно «не могу», пока не доказано иное, либо «да». Но так поступать слишком жестоко.

Хочешь жить в своем манямирке — да пожалуйста, у меня абсолютно нет мотивации тебя оттуда вытаскивать.

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

В данном случае помножить на ноль табуретку я могу простым вопросом «я прав?». И тут у табуретки два варианта - «нет», а далее «я могу, но не хочу», что эквивалентно «не могу», пока не доказано иное, либо «да». Но так поступать слишком жестоко.

Уважаемый :-) Вот ты простыни пишешь, а зачем? :-) Мне бы понять :-)

Только Release поставьте.

Ну да, ну да, а от богомерзких «c++» это тогда чем отличается?

Тебя обманули - тебе дали пример, который не про уб, а ты в ответ дал согласие и сказал, что это поведение компилятора «жабисткое». Зря.

Данный пример про то, что n * 8 == 0, только при n == 0, а это значит, что умножение в данном случае не имеет смысла. Его и выкинуло, а далее код работает так, как и должен.

Эта оптимизация построена на том, что компилятор не предполагает переполнения. И это правильная логика - не жабистская. Тот же контекст, который определил ты предполагает то, что компилятор ПОНИМАЕТ, что там УБ и он использует ФАКТ наличия УБ для того, чтобы генерить РАНДОМНОЕ ДЕРЬМО.

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

а от богомерзких «c++» это тогда чем отличается?

Тем что в C++ есть UB а тут нет

стандарт 98го года определял, что корректно скомпилированная программа обязана была работать с volatile-переменныеми и вызывать внешние функции в том порядке, как это в коде. Но сейчас это время прошло.

Ээ, а что там могло поменяться? volatile и сейчас определяется как запрет на изменение семантики. Про внешние функции не видел запрета, скорее про них просто ничего не известно, поэтому переставить не получится (но с LTO уже не факт).

Тем, что в с++ падает release, а в rust - debug.

Тем что в C++ есть UB а тут нет

А почему тогда поведение в варианте Debug не такое же, как в варианте Release?

Тебя обманули - тебе дали пример, который не про уб

Никто не обманывал, как раз в этом случае компилятор воспользовался UB чтобы убрать умножение.

Я уже 10раз это говорил. Подобные персонажи существует только по причине слабости аудитории. И если я хочу вменяемой дискуссии, вменяемых компетентных пацанов, то я обязан работать с аудиторией и показывать им повадки подобных персонажей. Поскольку я вижу, что аудитория сама не может, а если и может, то малая её часть.

Поэтому простыни я пишу не подобным персонажам - это не имеет смысла, а людям вменяемым.

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

Люди верили, что шланг был быстрее гцц - уже не верят. Люди верили, что обработка ошибок работы с памятью позволяет что-то гарантировать - сейчас нет. Даже явные сектанты обратного вынуждены это признавать.

И потихоньку аудитория меняется.

И потихоньку аудитория меняется.

Без пруфов нещитово.

И если я хочу вменяемой дискуссии

Поцыэнт с расстройствами психики хочет вменяемости. Таки запишем.

Потому что так решили авторы языка, что в Debug режиме будут включены все проверки на переполние. Вот цитата из RFC:

Additionally, when building in a default «debug» configuration (i.e., whenever debug_assert would be enabled), overflow checking should be enabled by default, unless the user explicitly requests otherwise. The precise control of these settings is not detailed in this RFC.

The goal of this rule is to ensure that, during debugging and normal development, overflow detection is on, so that users can be alerted to potential overflow (and, in particular, for code where overflow is expected and normal, they will be immediately guided to use the wrapping methods introduced below). However, because these checks will be compiled out whenever an optimized build is produced, final code will not pay a performance penalty.

обязанность доказательств лежит на утверждающей стороне

Какое конкретно из моих утверждений вызывает у тебя сомнения? Жду ссылку/цитату.

Тем, что в с++ падает release, а в rust - debug.

очень толсто.