Если мы успели разыменовать указатель, и компилятор это увидел, он автоматически считает, что указатель не NULL, а значит проверка лишняя и её можно выкинуть.
Сравнение с NULL выкидывается не потому что в нём UB, а потому что указатель не NULL, иначе бы предыдущее разыменование приводило к UB. Поскольку в программе UB не может использоваться, значит условие можно выкинуть.
6.5.3.2 If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined. Плюс сноска: Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer...
Ты мог взять указатель на переменную на стеке и передать в функцию, проверяющую указатель на NULL. В каком месте и зачем писать прагму? Что делать, когда прагма устареет, а ты забудешь её обновить?
Количество false-positive будет нереально большим, зачем это нужно? Вот пример, у тебя есть указатель на структуру, ты его разыменовываешь для каких-нибудь целей, а потом ниже по коду вызываешь другую функцию, в которой есть проверка на NULL. Компилятор инлайнит вторую функцию, видит проверку на NULL после разыменовывания, и зная про UB может эту проверку выкинуть. Но на что тут жаловаться и главное зачем?
Я что-то не понял первый пример, как data может указывать на factor, если factor - локальная для этой функции переменная? Или компилятор исходит из того, что мы в вызывающей функции можем сформировать указатель на локальную переменную вызываемой?
Ну вот правда, то будет делать бомбу с bt и называть устройство так
Тот, кто хочет взорвать эту бомбу, но подсознательно не хочет доводить до этого, поэтому оставляет шанс быть обнаруженным. Совсем не редкая ситуация, поэтому специалисты по безопасности всегда реагируют на такие вещи. На этот счёт рекомендую почитать "The Gift of Fear: Survival Signals That Protect Us from Violence" by Gavin de Becker.
Что значит "честная" или "нечестная" с точки зрения теории вероятностей? Мы же просто обсуждаем вероятности выиграть. Дело игрока менять или не менять дверь, теория говорит, что матожидание смены будет в пользу игрока.
Да, только исход противоположный. Если держались за дверь с теслой с вероятностью 1/3, то открыв вторую, получим козу с той же вероятностью. Или что то же самое, с вероятностью 2/3 держались за дверь с козой и поменяв выбор получим теслу.
В обычной программе таких диагностик будут сотни, а польза совершенно неочевидна. Каждое разыменование указателя теперь подписывать прагмой, что ли?
Если заинлайнит, то может. Вопрос в том, зачем тут диагностика, куда пихать прагму и как следить за её валидностью.
Если мы успели разыменовать указатель, и компилятор это увидел, он автоматически считает, что указатель не NULL, а значит проверка лишняя и её можно выкинуть.
Сравнение с NULL выкидывается не потому что в нём UB, а потому что указатель не NULL, иначе бы предыдущее разыменование приводило к UB. Поскольку в программе UB не может использоваться, значит условие можно выкинуть.
6.5.3.2 If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
Плюс сноска: Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer...
Разыменование NULL является UB, поэтому увидев проверку на NULL после разыменования компилятор вправе выкинуть проверку.
Ты мог взять указатель на переменную на стеке и передать в функцию, проверяющую указатель на NULL. В каком месте и зачем писать прагму? Что делать, когда прагма устареет, а ты забудешь её обновить?
Количество false-positive будет нереально большим, зачем это нужно? Вот пример, у тебя есть указатель на структуру, ты его разыменовываешь для каких-нибудь целей, а потом ниже по коду вызываешь другую функцию, в которой есть проверка на NULL. Компилятор инлайнит вторую функцию, видит проверку на NULL после разыменовывания, и зная про UB может эту проверку выкинуть. Но на что тут жаловаться и главное зачем?
А на практике это UB, которого пугаются сишники и хотят избавиться от самого понятия, хотя оптимизация в принципе возможна именно потому что он есть.
Тоже склоняюсь к этому варианту. Вроде по отдельности слова логичные, но смысл полный бред.
Я про этот коммент и пишу, он бессмысленный.
И? Какая разница, функция оперирует своей локальной копией, которая по соглашению вызовов вообще могла прийти в регистре.
В примере 4 никакого UB нет, там же знаковые инты, они могут быть меньше нуля и приводить к сумме меньше нуля безо всякого переполнения.
Я что-то не понял первый пример, как data может указывать на factor, если factor - локальная для этой функции переменная? Или компилятор исходит из того, что мы в вызывающей функции можем сформировать указатель на локальную переменную вызываемой?
Потому что реальные террористы делают то же самое.
Тот, кто хочет взорвать эту бомбу, но подсознательно не хочет доводить до этого, поэтому оставляет шанс быть обнаруженным. Совсем не редкая ситуация, поэтому специалисты по безопасности всегда реагируют на такие вещи. На этот счёт рекомендую почитать "The Gift of Fear: Survival Signals That Protect Us from Violence" by Gavin de Becker.
Кто бы говорил.
Или скажет "надоело мне такие задачи решать, пойду в покер играть лучше". Или попадёт под автобус. Или нажрётся водки и сделает хуже.
Что значит "честная" или "нечестная" с точки зрения теории вероятностей? Мы же просто обсуждаем вероятности выиграть. Дело игрока менять или не менять дверь, теория говорит, что матожидание смены будет в пользу игрока.
Да, только исход противоположный. Если держались за дверь с теслой с вероятностью 1/3, то открыв вторую, получим козу с той же вероятностью. Или что то же самое, с вероятностью 2/3 держались за дверь с козой и поменяв выбор получим теслу.