LINUX.ORG.RU

Чудесный код С++

 


0

2

Хотите поржать?

BOOL ShaderElement::equal(ShaderElement* S)
{
    if (nullptr == S && nullptr == this)
        return TRUE;
    if (nullptr == S || nullptr == this)
        return FALSE;
    return equal(*S);
}
Как вы думаете, для чего оно?

gcc само собой выкидывает бессмысленные проверки, valgrind показывает что чуть позже происходит повреждение памяти. А на винде этот код работает!!! Так что это тупо защита от быдлокода, который вызывает потерю контекста.

★★★★★

Последнее исправление: eagleivg (всего исправлений: 2)
Ответ на: комментарий от missxu

Помогите разобраться, это баг LLVM или нет

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

также еще одни бинарники можно тут смотреть

Бинарники смотреть не интересно. Интересно посмотреть на код. Желательно не простыню на 2500 строк, а что-нибудь покороче.

но факт сборки без багов под x86_64 остается фактом

Это очень похоже на UB. Там иногда компилятор генерит то, что ты от него хотел. А иногда — нет.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat
class C{
private:
   int b[2];
public:
   C();

};

C::C()
{
    b[0] = 2;
    b[1] = 3;
}

и любая инициализация массива «не через цикл for(){элемент=значение;}» даст 100% краш/UB(массив будет не инициализирован всегда с мусором) бинарника скомпилленного в clang при первой компиляции(когда байткоды либ для llvm не собраны) такого кода, в clang полугодичной давности(возможно щас уже нет, я пе обновлял еще)
банально запустив компиляцию еще раз все станет нормально(либо инициализировать все массивы циклом for тогда тоже с 1 раза будет норм)

возможно ты просто не работаешь с clang(кросскомпиляцией) и не в курсе местных «фич»

missxu
()
Ответ на: комментарий от missxu

да багрепорты слать, или даже говорить об этом на стаковерфлове/ексченже не имеет смысла

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

возможно поэтому в интернете почти нет сообщений про «кривости clang», он слишком быстро обновляется (достаточно вспомнить весь ад кривой компиляции шейдеров в llvm лля радеонов, и скорость выхода новых версий llvm(каждый день и чаще))

missxu
()
Ответ на: комментарий от anonymous

Скорость работы не измеряется голым количеством инструкций.

anonymous
()
Ответ на: комментарий от i-rinat

а зачем лямбда, если шланг ему перманентно в штаны срёт?

anonymous
()
Ответ на: комментарий от i-rinat

тогда я пас. мипса под рукой нет.

а вообще, 2018-й уже успел утомить обсуждением последствий ub.

anonymous
()
Ответ на: комментарий от i-rinat

тут нигде, баг с лямбдами был в «до полугодичного обновления» сейчас уже нет, просто он мне кучу времени съел

сейчас(неделю назад) встретил тот что показал

помимо десятка мелких которые я уже просто игнорю

missxu
()
Ответ на: комментарий от anonymous

яж не спорю, баг может быть вообще с процессором(собираю на одном ПК все) или с левыми либами какимито(несмотря на то что собираю на Вин/Линукс/и еще кросскомпиляция)

missxu
()
Ответ на: комментарий от anonymous

и да я говорил про компиляцию в *.bc и после уже компиляцию в нужную архитектуру

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

missxu
()
Ответ на: комментарий от missxu

Знаешь, если действительно такой баг с инициализацией, это просто жуткий фейл. Настолько жуткий, что сложно поверить, что в таком проекте будет такой баг. Ты уверен, что не пытаешься в одну и ту же память писать дважды? Use-after-free?

i-rinat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.