Здравствуйте, σ, Вы писали:

σ>>>И чо, для `a` == `*(volatile int*)0` тоже должно работать?
_>>Где в объявлении unsigned a; есть указание на *(unsigned volatile*)0 ?

σ>А почему закон не должен выполняться для любого `a` (нужного типа)?
Переформулируйте вопрос. Что такое нужный тип и кто такой любой a, и какой закон не должен выполняться?

Здравствуйте, kov_serg, Вы писали:

_>Удивительно потому что unsigned не содержит таких значений. double содержит inf,-0,nan, но unsigned нет. И для всех элементов представимых типом unsigned "a-a" всегда 0
Это уже только на некоторой целевой платформе, в runtime, unsigned переменная будет представлена набором бит, все комбинации из которых имеют какое-либо числовое значение. Но в семантике языка c++, в compile time, переменная unsigned кроме этих значений можеть иметь еще и, как уже ранее упоминалось, значение indeterminate.

_>>Удивительно потому что unsigned не содержит таких значений. double содержит inf,-0,nan, но unsigned нет. И для всех элементов представимых типом unsigned "a-a" всегда 0
V>Это уже только на некоторой целевой платформе, в runtime, unsigned переменная будет представлена набором бит, все комбинации из которых имеют какое-либо числовое значение. Но в семантике языка c++, в compile time, переменная unsigned кроме этих значений можеть иметь еще и, как уже ранее упоминалось, значение indeterminate.

Свидитель секты «у объекта не может быть больше значений, чем различных битовых паттернов в его value representation»?

Здравствуйте, 5.März, Вы писали:

M> ·>??? Это почему?
M> Креши и уязвимости есть в любом более-менее большом проекте, они практически всегда связаны с UB.
Не очень ясно причём тут оптимизатор. Тут сама философия того, что в C/C++ так много UB. Было бы лучше в спеке языка обозначить, что UB — ошибка компиляции. Но я затрудняюсь предсказать последствия такого.. проще уж другой язык взять.
Правда UB это следствие другой философии — не делать лишнего.

ошибка компиляции
clang

Здравствуйте, kov_serg, Вы писали:

_>От чего может зависеть результат? И почему clang начиная с 5-ой версии считает что 0 будет самый раз?

Я так понимаю, ты ожидаешь от компилятора глубоких размышлений на тему, "to be or not to be, there is a question".

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

Здравствуйте, ·, Вы писали:

·>Было бы лучше в спеке языка обозначить, что UB — ошибка компиляции. Но я затрудняюсь предсказать последствия такого.. проще уж другой язык взять.

UB не может быть ошибкой компиляции когда есть позволенный стандартом способ скомпилировать без UB. О том весь и сыр-бор насчет optimization-unsafe code.

Здравствуйте, 5.März, Вы писали:

5M>·>Было бы лучше в спеке языка обозначить, что UB — ошибка компиляции. Но я затрудняюсь предсказать последствия такого.. проще уж другой язык взять.

5M>UB не может быть ошибкой компиляции когда есть позволенный стандартом способ скомпилировать без UB. О том весь и сыр-бор насчет optimization-unsafe code.
Почему не может? В той же java такой код будет ошибкой компиляции, по стандарту. Причём тут оптимизации?

Здравствуйте, kov_serg, Вы писали:

Q>>Выглядит как UB, и компилятор пользуется своим правом произвола. Вероятно, он просто сгенерировал возврат нуля, задетектив UB.

_>Как вы относитесь к такому праву?

Это инженерный компромисс между быстродействием и безопасностью. C++ позиционируется как "быстрый язык". Если же нужно кидать вэлью лопатами, java/C# будут лучшим выбором.

R>ошибка компиляции
R>clang
Программа IFNDR, компилятор можеть хоть в int main() { return 0; } это превратить.

подразумевалось что constexpr хороший ub занитайзер
а с учетом того что сейчас constexpr натягивают на все
уже и на class base constexpr судя по новым отчетам с меил лист, то про ill formed можно будет вообще забыть в скором будущем

R>подразумевалось что constexpr хороший ub занитайзер

Подразумевалось, что для этого его надо правильно готовить.

Здравствуйте, kov_serg, Вы писали:

По идее тут написавшего такое надо приговорить к расстрелу 20 раз.
Если ревьюер такое пропустил, то его 40 раз.

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

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

Здравствуйте, kov_serg, Вы писали:

_>Знатоки стандарта, что вас давно не слышно. Что должна вернуть функция?
_>

_>int fn() { int x; return x || !x; }
_>

В данном случае, функция никому ничего не должна.

_>От чего может зависеть результат?

От чего угодно. Фазы луны, например. Или глубины депрессии.

_>И почему clang начиная с 5-ой версии считает что 0 будет самый раз?

Потому что имеет на это полное право. А чтоб наглядней было, можно еще вот так:

https://godbolt.org/z/b44de6h8q

int fn() { int x; return x == x; }

P.S. Тебе уже сто раз все объяснили, но ты продолжаешь упрямствовать. А на чем, собственно, основана твоя уверенность, что правила математики применимы к x?

Здравствуйте, rg45, Вы писали:

R>Потому что имеет на это полное право. А чтоб наглядней было, можно еще вот так:
R>https://godbolt.org/z/b44de6h8q
R>

R>int fn() { int x; return x == x; }
R>

R>P.S. Тебе уже сто раз все объяснили, но ты продолжаешь упрямствовать. А на чем, собственно, основана твоя уверенность, что правила математики применимы к x?
Чем плохи правила математики? Они не противоречивые. Но тут полная фигня. Любое появления новых правил с потолка приводят к печальным последствиям появлению только костылей. А уж когда на основе таких правил преобразуют код это вообще полный ужас. Можно тушить свет и сливать воду.
Мне не понятно одно: упрямство окружающих с пеной у рта защищающих подобное поведение. Разве не очевидно что подобные правила только умножают скорбь сложность, привнося хаос новые сущности на ровном месте, ничего не давая взамен.

Здравствуйте, kov_serg, Вы писали:

_>Чем плохи правила математики?

А кто говорит, что они плохи? Просто не всегда применимы. Тебя же не удивляет, например, что результат сложения некоторых объектов целых типов не соответствует правилам математики. Или удивляет?

Здравствуйте, rg45, Вы писали:

_>>Чем плохи правила математики?

R>А кто говорит, что они плохи? Просто не всегда применимы. Тебя же не удивляет, например, что результат сложения некоторых объектов целых типов не соответствует правилам математики. Или удивляет?
У меня у целых типов модульная арфметика и поэтому всё строго с правилами. Ломаются правила математики только с целыми типами с насыщением.
А вас не удивляет что в тип пытаются добавить новый элемент, который в этом типе не возможн (не представим) и этим значением ломают все остальные операции для допустимых значений? При этом дальше с подобным значением делают преобразования, которые влияют на резульирующий код, забывая что данное значение не поддреживает никаких преобразований ибо они для него противоречивы.

Здравствуйте, kov_serg, Вы писали:

_>У меня у целых типов модульная арфметика и поэтому всё строго с правилами.

А кого волнует, что там У ТЕБЯ? Правила математики, они не у тебя. И в каких-то прикладных аспектах они работают, в каких-то нет. Нравится тебе это или нет.

Здравствуйте, rg45, Вы писали:

R>А кого волнует, что там У ТЕБЯ? Правила математики, они не у тебя. И в каких-то прикладных аспектах они работают, в каких-то нет. Нравится тебе это или нет.
Мне это категорически не нравиться. Ибо сличком много исключений из правил так где это совершенно не нужно. И закладывать гавно в фундамент это так себе идея.

Здравствуйте, kov_serg, Вы писали:

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

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