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

SP>а тут уже начинается интересный пласт вопросов.
Некоторые ЯП ответили на этот пласт вопросов. Скажем в java компилятор имеет правила что когда выходит и т.п. Например "while(true){...}" — компилятор понимает, что цикл бесконечный и после него unreachable, но если есть break — то уже конечный. А так же логика exhaustive switch-case и т.п.
Вот это пусть и компиляторщиков голова болит как это всё проверять, а не у меня, как разработчика.

SP>Доказать, что функция не на всех возможных путях вернула значение (что как я догадываюсь, теоретически невозможно)
Так а зачем в принципе писать такой код, который даже теоретически невозможно доказать корректность? Тем более в таких тривиальных случаях... Жопсекьюрити что-ли?

SP>    if((flag & 1) == 0){
SP>        return 1;
SP>    }
SP>}

SP>не будем придираться к самой функции. Поколения криворуких программистов могут сделать и не такое. Тут формально return нет и clang честно пишет предупреждение control reaches end of non-void function но в asm генерирует абсолютно корректный код. То есть компилятор признал что код с душком,
А вот надо придраться! Код пишется для человеков, а не для компилятора. Мне, как человеку, хочется видеть надёжный очевидный код. Я предпочитаю, чтобы было тупо — скомпилировалось, значит работает. Я слишком тупой, чтобы на ходу выполнять битовые операции и в голове представлять что где может быть пропущено.
В случае если очень надо, то есть std::abort/std::unreachable — их видно явно и становится понятно, что тут нечто особенное на что стоит обратить внимание.

SP>но полез делать маленькие оптимизации из предположения что это корректная программа и смог дойти до правильного ответа.
SP>А теперь представим, что у нас не такой синтетический пример, а что-то реальное с закрученной логикой листов на 5.
Именно. Как ты с логикой на 5 листов поймёшь, что ничего не пропущено? Особенно когда смотришь PR и никаких warnings не видишь.

SP>p.s опять же UB тут по ветке по-моему понимают несколько привратно. Дескать если компилятор видит UB, он может делать любую дичь. Но он как раз предполагает, что в программе UB быть не может и делает оптимизации из этого предположения. То есть если в программе на какой-то ветке нет return, да, для компилятора это сигнал что тут UB. Но он сделает предположение, что программа туда просто не дойдёт или в этом случае никто результат проверять не будет. То есть в runtime всё сложится так, что в конечном коде UB исчезнет.
SP>Что произошло у ТС — не понимаю. Возможно, это бунт разработчиков компилятора, их следует признать еретиками и сжечь на костре.
Сабж как раз о том, что раньше всё работало, а потом ВНЕЗАПНО стало падать в рантайме. Мой поинт — должно падать в компайл-тайме!

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

SP>а тут уже начинается интересный пласт вопросов.
Некоторые ЯП ответили на этот пласт вопросов. Скажем в java компилятор имеет правила что когда выходит и т.п. Например "while(true){...}" — компилятор понимает, что цикл бесконечный и после него unreachable, но если есть break — то уже конечный. А так же логика exhaustive switch-case и т.п.
Вот это пусть и компиляторщиков голова болит как это всё проверять, а не у меня, как разработчика.

SP>Доказать, что функция не на всех возможных путях вернула значение (что как я догадываюсь, теоретически невозможно)
Так а зачем в принципе писать такой код, который даже теоретически невозможно доказать корректность? Тем более в таких тривиальных случаях... Жопсекьюрити что-ли?

SP>    if((flag & 1) == 0){
SP>        return 1;
SP>    }
SP>}

SP>не будем придираться к самой функции. Поколения криворуких программистов могут сделать и не такое.
Так ведь в данном случае — лишь потому что компилятор по кривым ручкам не бьёт. А может. Но вместо этого, как обычно, стреляет в ногу!

SP>Тут формально return нет и clang честно пишет предупреждение control reaches end of non-void function но в asm генерирует абсолютно корректный код. То есть компилятор признал что код с душком,
А вот надо придраться! Код пишется для человеков, а не для компилятора. Мне, как человеку, хочется видеть надёжный очевидный код. Я предпочитаю, чтобы было тупо — скомпилировалось, значит работает. Я слишком тупой, чтобы на ходу выполнять битовые операции и в голове представлять что где может быть пропущено.
В случае если очень надо, то есть std::abort/std::unreachable — их видно явно и становится понятно, что тут нечто особенное на что стоит обратить внимание.

SP>но полез делать маленькие оптимизации из предположения что это корректная программа и смог дойти до правильного ответа.
SP>А теперь представим, что у нас не такой синтетический пример, а что-то реальное с закрученной логикой листов на 5.
Именно. Как ты с логикой на 5 листов поймёшь, что ничего не пропущено? Особенно когда смотришь PR и никаких warnings не видишь.

SP>p.s опять же UB тут по ветке по-моему понимают несколько привратно. Дескать если компилятор видит UB, он может делать любую дичь. Но он как раз предполагает, что в программе UB быть не может и делает оптимизации из этого предположения. То есть если в программе на какой-то ветке нет return, да, для компилятора это сигнал что тут UB. Но он сделает предположение, что программа туда просто не дойдёт или в этом случае никто результат проверять не будет. То есть в runtime всё сложится так, что в конечном коде UB исчезнет.
SP>Что произошло у ТС — не понимаю. Возможно, это бунт разработчиков компилятора, их следует признать еретиками и сжечь на костре.
Сабж как раз о том, что раньше всё работало, а потом ВНЕЗАПНО стало падать в рантайме. Мой поинт — должно падать в компайл-тайме!