Does this program have undefined behavior?

[Phil Carmody]

True. But I challenge you to to describe a hypothetical
non-contrived conforming C implementation in which common initial
sequences for structs work *only* when they're in a union.

Challenges, not being explicitly defined by the C standard,
yield undefined behaviour. Consider yourself lucky - you won
a shrug.

Phil

 

[Anand Hariharan]

Luca Forlizzi wrote: (...)

The above two are definitely undefined IMHO.

Why is the second example undefined? Doesn't the comma operator
introduce a sequence point?

The above probably is because the multiply by 0 means the value to be
assigned to i can be known prior to calling g.

I disagree. What if g() returns NaN? The compiler cannot
(shouldn't?) assume the result of this expression as a given before
calling g().


And I personally think that is just reprehensible. I write this after
looking at Pete and Keith Thompson's follow-ups in the parallel sub-
thread, and I agree with Pete.

C should allow for some UB (like squishing a value into a particular
address), but this is one source of UB that is pernicious and serves
no useful purpose.

- Anand

 

[Charlton Wilbur]

(referring to i = x * g(); )

N> I understood the post previous to mine in the thread to say that
N> if x in the above was a constant zero, then even if g would
N> normally be defined (although it modifies i) then it wouldn't be,
N> because the multiplication zero allows the result of x to be
N> discarded, and so for the assignment of 0 to i and the alteration
N> in g to happen "out of order".

No, because the sequence point at the semicolon following the statement
in g() which modifies i means that all side effects have taken place at
that point. The side effect of modifying i can't hang around through
multiple sequence points before being resolved, which is what your
theory requires.

N> So my point was that if the optimiser can see that x will always
N> be zero by this point, then it can make the optimisation, and
N> then we will get undefined behaviour.

Er, no. The C standard does not allow for short-circuit evaluation of
operands aside from those to && and ||. Now, the "as if" rule means
that the optimizer is allowed to do whatever it likes to the code so
long as the actual result is the same as it would be if there were no
optimization.

So even if you wrote i = 0 * g(); explicitly, the translated code would
have to evaluate g() and handle its side effects.

Charlton

 

[Charlton Wilbur]

LF> However, Mr. Kirby wrote in 1994. It may be that there has been
LF> some official statement from the Committee clarifying the issue.
LF> Does anyone know?

More relevantly, Mr Kirby was writing about C++.

Charlton

 

[lawrence.jones]

So this confirms that Mr. Kirby interpretation of C89/C99 was sound,
requiring a change to make (or at least to clearly make)
such expressions well defined.

That's an unwarranted conclusion. The changes were simply to support
multiple threads; they were not intended to change the required behavior
for a single thread.

 

[Nick Keighley]

Oxydative stress.

Then if we all used fluorine instead of oxygen for our redox reactions which
sustain life, the fluorine would be considerably more efficient, and food
would go further. So we'd need less farmland and the environment would
prosper.

As my chemistry teacher told us "you can always spot someone who works
with flourine, because of the missing fingers and so on. Pretty much
everything interesting in fluourine chemistry is either explosive or
corrosive or both"

 

[Nick Keighley]

In








I never knew baking was so dangerous.


Well, I know about the explosive part - Washburn A Mill and all that.