CD
мне кажется, что утверждение inttoptr(ptrtoint(x)) is the same as x это вообще единственная гарантия, которая даётся про преобразования указателя в число
Size: a a a
2021 March 14
D
мне кажется, что утверждение inttoptr(ptrtoint(x)) is the same as x это вообще единственная гарантия, которая даётся про преобразования указателя в число
Ну вот научи ее компилятов соблюдать
D
Below, I will show a series of three compiler transformations that each seem “intuitively justified”, but when taken together they lead to a clearly incorrect result. I will use LLVM for these examples, but the goal is not to pick on LLVM—other compilers suffer from similar issues. The goal is to convince you that to build a correct compiler for languages permitting unsafe pointer manipulation such as C, C++, or Rust, we need to take IR semantics (and specifically provenance) more seriously.
Так и что?
CD
Dima
Ну вот научи ее компилятов соблюдать
Что значит "научи компилятор соблюдать"? Языковые ограничения не распространяются на компилятор
CD
Реализация strlen в libc может выходить за границы массива и от этого компилятор не UBает
D
Что значит "научи компилятор соблюдать"? Языковые ограничения не распространяются на компилятор
Ещё как распространяются
CD
Dima
Ещё как распространяются
Не UBает, UB - термин стандарта, стандарт описывает поведение программы на языке, а не поведение компилятора
А
Не UBает, UB - термин стандарта, стандарт описывает поведение программы на языке, а не поведение компилятора
На самом деле уб в стандарте развязывает компилятору руки. И компилятор может делать вообще что угодно. В этом то проблема
CD
Это из серии "код <stdio.h> написан на С" - нет, не написан
А
Dima
Так и что?
И смысл тогда брать гцц?
А
На самом деле уб в стандарте развязывает компилятору руки. И компилятор может делать вообще что угодно. В этом то проблема
В том числе и проводить в итоге некорректные оптимизации. Или не проводить
D
Не UBает, UB - термин стандарта, стандарт описывает поведение программы на языке, а не поведение компилятора
Имеет ли право комплятор свести три atomic_load_relaxed в один? Естественно между ними ничего нету, и и в качестве аргумента у них одикавовый параметр
D
И смысл тогда брать гцц?
Гсс гораздо надёжнее, ему Линукс кернел приходится поддерживать
А
Dima
Гсс гораздо надёжнее, ему Линукс кернел приходится поддерживать
Сильное заявление
CD
Dima
Имеет ли право комплятор свести три atomic_load_relaxed в один? Естественно между ними ничего нету, и и в качестве аргумента у них одикавовый параметр
Это правильный вопрос. Для любой программы стандарт определит одно из следующих поведений - well defined, implementation-defined, unspecified, undefined. Что-то мне подсказывает, что вопрос о равенстве целочисленных значений указателей не относится к первым двум, так что компилятор делает что угодно и не обязан это декларировать
D
Сильное заявление
Так и есть
А
Dima
Так и есть
Ну конечно
CD
Скорее всего я чуть ошибаюсь и ответ в данном случае не undefined а unspecified и сравнение выдаст какой-то результат, но это совершенно точно не означает, что компилятор не может считать результат этого сравнения разным в разных строках кода
D
Это правильный вопрос. Для любой программы стандарт определит одно из следующих поведений - well defined, implementation-defined, unspecified, undefined. Что-то мне подсказывает, что вопрос о равенстве целочисленных значений указателей не относится к первым двум, так что компилятор делает что угодно и не обязан это декларировать
Нет, правильный ответ, хрен его знает может быть и можно но мы насколько хз что делать с атомиками, что ничего не будем оптимизировать
А
Dima
Гсс гораздо надёжнее, ему Линукс кернел приходится поддерживать
Но вообще вроде как и clang можно ядро собрать