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

Для… сравнения?

Был готовый метод BOOL ShaderElement::equal(const ShaderElement &S), к нему в пару решили сделать метод BOOL ShaderElement::equal(ShaderElement* S). Реализующий боялся, что если S == nullptr, произойдёт разыменование nullptr в *S, поэтому добавил проверок. Ещё он не знал, что this никогда не бывает равно nullptr, поэтому заморочился ещё и этим вариантом.

Ещё он не знал, что this никогда не бывает равно nullptr

Я просто оставлю это здесь: https://ideone.com/ePI6dO. И да, я знаю, что это UB.

Юмор в том, что как раз знал. Под линуксом падает чуть дальше, в том самом вызове equal(*S) и в отладчике видно, что this=0. https://cdn.discordapp.com/attachments/410452181213249546/497388465382621224/...
А под виндой работает.

Под линуксом падает чуть дальше, в том самом вызове equal(*S) и в отладчике видно, что this=0

Порча памяти?

Да.

Invalid read of size 1
  в ShaderElement::equal(ShaderElement&) в /home/builder/xray-16/src/Layers/xrRender/Shader.cpp:95
Address 0x8 is not stack'd, malloc'd or (recently) free'd  1: ShaderElement::equal(ShaderElement&) в /home/builder/xray-16/src/Layers/xrRender/Shader.cpp:95
  2: Shader::equal(Shader&) в /home/builder/xray-16/src/Layers/xrRender/Shader.cpp:125
  3: CResourceManager::_lua_Create(char const*, char const*) в /home/builder/xray-16/src/Layers/xrRenderPC_GL/glResourceManager_Scripting.cpp:521
  4: resptrcode_shader::create(char const*, char const*, char const*, char const*) в /home/builder/xray-16/src/Layers/xrRender/Shader.cpp:21
  5: CPSLibrary::Load(char const*) в /home/builder/xray-16/src/Layers/xrRender/PSLibrary.cpp:259
  6: CPSLibrary::OnCreate() в /home/builder/xray-16/src/Layers/xrRender/PSLibrary.cpp:28
  7: CRender::create() в /home/builder/xray-16/src/Layers/xrRenderPC_GL/rgl.cpp:358
  8: D3DXRenderBase::OnDeviceCreate(char const*) в /home/builder/xray-16/src/Layers/xrRender/r__dsgraph_build.cpp:895
  9: CRenderDevice::Create() в /home/builder/xray-16/src/xrEngine/Device_create.cpp:71
  10: Startup() в /home/builder/xray-16/src/xrEngine/main.cpp:196
  11: RunApplication() в /home/builder/xray-16/src/xrEngine/main.cpp:295
  12: entry_point(char const*) в /home/builder/xray-16/src/xr_3da/entry_point.cpp:45
  13: main в /home/builder/xray-16/src/xr_3da/entry_point.cpp:100

Ну, рукожопие — один из самых распространённых недугов, которые можно встретить в разработке :)

У меня самого с работы просто адское количество примеров на уровне твоего.

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

Кстати я видел такой код (с проверкой на нуль в деструкторе), который и под gcc вполне себе работал. Или в деструкторе не UB?

D3DXRenderBase::OnDeviceCreate

gcc

gdb

А это как так вышло? D3D под онтопик есть?

Дай угадаю - на самом высоком уровне ловятся все seh, и стоит catch(...)?

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

C++ ликбез:

1) this может быть null

2) ссылка (референс) тоже может быть null

3) жизнь — боль

Настоящий параноик дописал бы

if (nullptr == &ShaderElement::equal)
    return FALSE;

А это как так вышло? D3D под онтопик есть?

Просто базовый класс рендера так называется. Исходно под винду, но надеюсь скоро запустим под онтопик.

И

if (nullptr != nullptr) {
   return FALSE;
} else if (nullptr != NULL) {
   throw std::runtime_error("Broken runtime");
}

А, ну удачных удач на этом нелёгком пути :)

Ещё он не знал, что this никогда не бывает равно nullptr

Сэр не видел MSVS и clang-а
не бывает)))) угу какже

перваяже лямбда(сложнее хело ворда) такой ад устроит с nullptr, никаких проверок не хватит

не бывает

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

Поэтому — не бывает. Если в коде где-то this оказался равным nullptr, нужно фиксить код, потому что одна заплатка проблем не решит.

Поэтому — не бывает. Если в коде где-то this оказался равным nullptr, нужно фиксить код, потому что одна заплатка проблем не решит.

фиксить код на каждое минорное обновление clang-а?

ес че, в clang будет ад и ужас с UB, если у тебя лямбда 1000-го уровня вызывает this->, вызывает его из «другого контекста»(класса) и объект this не глобальный

я уже писал не раз даже на лоре об этой «фиче» clang
эта фича делает рандомный результат с каждой новой версией clang

с msvs тоже самое, в пределах одной версии MSVS

единственный вариант-полностью отказаться от всех фич C++11

будет ад и ужас с UB, если у тебя лямбда 1000-го уровня вызывает this->

единственный вариант-полностью отказаться от всех фич C++11

Я так понимаю, не писать лямбду 1000-го уровня — не вариант?

Я так понимаю, не писать лямбду 1000-го уровня — не вариант?

не писать цикл с 1000+ проходами
не делать рекурсию 1000+
не делать while(true)
на что ты еще готов ради компилятора?

на что ты еще готов ради компилятора?

Я готов не передёргивать свои аргументы. А ты?

Энтерпрайзно... Хотя, судя по количеству отписавшихся здесь о «this может быть равен nullptr» ничего удивительного

Пример давай. Наверняка у тебя адок с UB там.

не делать рекурсию 1000+

Вот это явно делать не стоит.

Как вы думаете, для чего оно?

Грязный хак чтобы починить неизвестно где возникший UB или битую память?

s/починить/скрыть

Тоже посмотрел на сталкера и испугался такого. Как поучаствовать? Wine используете? Пробовали с помощью clang в режиме совместимости под виндой собирать? Используете dr.memory?

Да, да, мы в курсе, что на винде просто работает, а на линуксе ошибки. Чо сказать хотел?

Почему? setrlimit(RLIMIT_STACK,(const rlimit[]){{RLIM_INFINITY,RLIM_INFINITY}});

В нетленку!

while-true-if-break наше всё!

не делать while(true)

Да! Нечего тратить такты на бессмысленную проверку константы true, правильно писать for (;;)

Если в коде где-то this оказался равным nullptr, нужно фиксить код

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

Компилятор похоже умнее тебя.

единственный вариант-полностью отказаться от всех фич C++11

Но очень не хочется, да?

У тебя детектор сарказма барахлит

не писать цикл с 1000+ проходами
не делать рекурсию 1000+
не делать while(true)

Чорт, не ожидал ))

скотина, ты?

Кстати, еще разит тотальное отсуствие const

rust все равно не взлетит

https://github.com/q4a/xray-16/ - там есть ссылка на diskord канал. Из wine таскаем некоторые енумы, силангом пробовали, собирается, dr.memory пробовал, не впечатлил по сравнению с valgrind.

потому что патлатое чудо решило не проверять на null при вызове метода объекта. а это 2 (две карл) ассемблерные инструкции.

если у тебя лямбда 1000-го уровня вызывает this->, вызывает его из «другого контекста»(класса) и объект this не глобальный

это называется кривые руки. язык программирования тут ни при чём.

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

С каких это пор this никогда не бывает равно nullptr?

T *t = nullptr;
t->callme ();

Вуаля

Вуаля

s/В/Ф/ s/a/б/

А вообще, UB: https://wandbox.org/permlink/iI9WNLsG6JgUAcRc

UB == место для оптимизции для компилятора, и, например, с очередным обновлением вместо nullptr в this окажется какой-то мусор (или указатель на другой обьект).

Т.е. я понимаю, что ты лишь хотел показать, что такое возможно. Но речь о том, что такое нельзя делать (в значении «лучше не делать»).

держи в курсе

Я так понимаю, примера мы не дождёмся?

Это UB.

Я так понимаю, примера мы не дождёмся?

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

GLSL демка/игра (играть онлайн) (комментарий)

также еще одни бинарники можно тут смотреть https://github.com/danilw/small-2d-game

баг только в clang, только при сборке не на x86_64
у меня есть MIPS и PPCпроцессоры, на которых я собирал для теста gcc-никаких утечек памяти и лямбды не исчезают
clang-ом собрал помимо wasm, только для MIPS(все очень плохо, сегфаулт на старте вообще)

по прежнему- возможно таки баг и у меня в коде/коде либы, но факт сборки без багов под x86_64 остается фактом