История изменений

Железо мешает и необходимость иметь не сложный компилятор - очевидно же…

Железо не мешает, это вопрос исключительно инвариантов в коде. Компиляторы Си уже весьма сложны, так что необходимость иметь несложный компилятор, похоже, не стоит так остро.

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

undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

Грубо говоря, для случаев, когда в функцию прилетает NULL, компилятор волен сгенерировать любое говно вместо кода. Например, выкинуть проверку.

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

Какую именно логику? С точки зрения языка, описанного в стандарте, компилятор ничего не ломает. Повторю цитату:

herefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3.

Доступ к обычным переменным не является побочным эффектом (side effect) с точки зрения абстрактной машины языка Си. Доступ к volatile переменным является. Пункт 5.1.2.3:

Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects,12) which are changes in the state of the execution environment

Компилятор Си гарантирует, что корректная программа (т.е. без UB) будет выполнять побочные эффекты в том порядке, в котором они описаны. Изменения же внутреннего состояния программы могут меняться порядком из-за оптимизаций. Хуже того…

In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced

… вычисления, которые не делают побочных эффектов, могут быть выкинуты нахер (например, вызов memset() чтобы занулить память с криптографическим ключом лол). Вот такая вот близость к ассемблеру, чувак.

т.е. ты можешь скомпилировать и все будет при любых тестах работать исправно, но после следующей компилиции ты сразу попадаешь на неправильное поведение

Оно является неправильным, это твоя программа неправильная. Потому что…

отсюда и мое слово «полечить проблему», по моему мнению volatile - это костыль и не более

… ты не знаешь языка, на котором пытаешься писать.

TL;DR: программа на языке Си модифицирует некое внешнее состояние (execution environment) относительно некоей абстрактной машины, описанной в стандарте (он правда довольно херово написан, если честно). Модификациями внешнего состояния (execution environment) являются: работа с файлами, сокетами, любыми другими внешними объектами, а также работа с volatile объектами. Порядок таких модификаций гарантируется стандартом (при условии отсутствия UB в программе). Порядок же любых других вычислений не гарантируется никак и никем и может быть любым. Вбей это себе в голову и перестань писать тут полную хероту.

Железо мешает и необходимость иметь не сложный компилятор - очевидно же…

Железо не мешает, это вопрос исключительно инвариантов в коде. Компиляторы Си уже весьма сложны, так что необходимость иметь несложный компилятор, похоже, не стоит так остро.

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

undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

Грубо говоря, для случаев, когда в функцию прилетает NULL, компилятор волен сгенерировать любое говно вместо кода. Например, выкинуть проверку.

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

Какую именно логику? С точки зрения языка, описанного в стандарте, компилятор ничего не ломает. Повторю цитату:

herefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3.

Доступ к обычным переменным не является побочным эффектом (side effect) с точки зрения абстрактной машины языка Си. Доступ к volatile переменным является. Пункт 5.1.2.3:

Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects,12) which are changes in the state of the execution environment

Компилятор Си гарантирует, что корректная программа (т.е. без UB) будет выполнять побочные эффекты в том порядке, в котором они описаны. Изменения же внутреннего состояния программы могут меняться порядком из-за оптимизаций. Хуже того…

In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced

… вычисления, которые не делают побочных эффектов, могут быть выкинуты нахер (например, вызов memset() чтобы занулить память с криптографическим ключом лол). Вот такая вот близость к ассемблеру, чувак.

т.е. ты можешь скомпилировать и все будет при любых тестах работать исправно, но после следующей компилиции ты сразу попадаешь на неправильное поведение

Оно является неправильным, это твоя программа неправильная. Потому что…

отсюда и мое слово «полечить проблему», по моему мнению volatile - это костыль и не более

… ты не знаешь языка, на котором пытаешься писать.

TL;DR: программа на языке Си модифицирует некое внешнее состояние относительно некоей абстрактной машины, описанной в стандарте (он правда довольно херово написан, если честно). Модификациями внешнего состояния являются: работа с файлами, сокетами, любыми другими внешними объектами, а также работа с volatile объектами. Порядок таких модификаций гарантируется стандартом (при условии отсутствия UB в программе). Порядок же любых других вычислений не гарантируется никак и никем и может быть любым. Вбей это себе в голову и перестань писать тут полную хероту.

Железо мешает и необходимость иметь не сложный компилятор - очевидно же…

Железо не мешает, это вопрос исключительно инвариантов в коде. Компиляторы Си уже весьма сложны, так что необходимость иметь несложный компилятор, похоже, не стоит так остро.

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

undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

Грубо говоря, для случаев, когда в функцию прилетает NULL, компилятор волен сгенерировать любое говно вместо кода. Например, выкинуть проверку.

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

Какую именно логику? С точки зрения языка, описанного в стандарте, компилятор ничего не ломает. Повторю цитату:

herefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3.

Доступ к обычным переменным не является побочным эффектом (side effect) с точки зрения абстрактной машины языка Си. Доступ к volatile переменным является. Пункт 5.1.2.3:

Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects,12) which are changes in the state of the execution environment

Компилятор Си гарантирует, что корректная программа (т.е. без UB) будет выполнять побочные эффекты в том порядке, в котором они описаны. Изменения же внутреннего состояния программы могут меняться порядком из-за оптимизаций. Хуже того…

In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced

… вычисления, которые не делают побочных эффектов, могут быть выкинуты нахер (например, вызов memset() чтобы занулить память с криптографическим ключом лол). Вот такая вот близость к ассемблеру, чувак.

т.е. ты можешь скомпилировать и все будет при любых тестах работать исправно, но после следующей компилиции ты сразу попадаешь на неправильное поведение

Оно является неправильным, это твоя программа неправильная. Потому что…

отсюда и мое слово «полечить проблему», по моему мнению volatile - это костыль и не более

… ты не знаешь языка, на котором пытаешься писать.

Железо мешает и необходимость иметь не сложный компилятор - очевидно же…

Железо не мешает, это вопрос исключительно инвариантов в коде. Компиляторы Си уже весьма сложны, так что необходимость иметь несложный компилятор, похоже, не стоит так остро.

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

undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

Грубо говоря, для случаев, когда в функцию прилетает NULL, компилятор волен сгенерировать любое говно вместо кода. Например, выкинуть проверку.

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

Какую именно логику? С точки зрения языка, описанного в стандарте, компилятор ничего не ломает. Повторю цитату:

herefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3.

Доступ к обычным переменным не является побочным эффектом (side effect) с точки зрения абстрактной машины языка Си. Доступ к volatile переменным является. Пункт 5.1.2.3:

Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects,12) which are changes in the state of the execution environment

Компилятор Си гарантирует, что корректная программа (т.е. без UB) будет выполнять побочные эффекты в том порядке, в котором они описаны. Изменения же внутреннего состояния программы могут меняться порядком из-за оптимизаций. Хуже того…

In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced

… вычисления, которые не делают побочных эффектов, могут быть выкинуты нахер (например, вызов memset() чтобы занулить память с криптографическим ключом лол). Вот такая вот близость к ассемблеру, чувак.

т.е. ты можешь скомпилировать и все будет при любых тестах работать исправно, но после следующей компилиции ты сразу попадаешь на неправильное поведение

Оно является неправильным потому что твоя программа неправильная. Потому что…

отсюда и мое слово «полечить проблему», по моему мнению volatile - это костыль и не более

… ты не знаешь языка, на котором пытаешься писать.