I just wrote a for-loop like this:
string foo="gazonk";
for(int i=0;i<sizeof(foo);i++) {
... do stuff ...
if (sometimes) foo = foo[1..];
... do stuff ...
}
The problem I discoverd was that when the length of foo is changed, the loop still tries to loop over the original length of foo. The problem dissappeard when I replace sizeof(foo) with a variable and update it when changing the length of foo.
Is this the correct behaviour or is the optimizer doing more than it should here?
I'll admit it is inconsitent, but I should have said "sizeof(b) should always be expanded to a constant b2 in the for expression". That is becouse for some reason I expect the optimizer to give me a set number of loops. I'll admit that it might not be as my mind makes it. ;-)
/ Peter Bortas
Previous text:
Expressions should *never* expand to constants unless they *are* constants. I suppose that a good optimizer could see if 'foo' were being changed in the loop, though.
Anyway, I can't repeat the problem:
int a=0; array foo=({1,2,3}); for (a=0; a<sizeof(foo); a++) { werror("%O\n",foo[a]); foo=foo[1..]; }
This happily outputs 1, 3 and exits for me.
/ Mirar
Previous text:
I don't believe you.
$ cat bug_l9908261.pike int main(int argc, array(string) argv) { string foo="gazonk"; int i;
for(i=0;i<sizeof(foo);i++) { if (i%2) { foo = foo[1..]; } } werror("i:%O\n", i); } $ ./pike -mmaster.pike bug_l9908261.pike i:4
Please provide an example that actually triggers the alleged bug.
/ Henrik Grubbström (Lysator)
Previous text:
Ok, with an actual sample of code that broke it was easy to fix. The bug was not in the optimization rule itself, which was sound, but in the dependency analyser. It didn't check arguments to side-effect free functions for written variables. Fixed in Pike 7.0, 7.2, 7.4 and 7.5.
/ Henrik Grubbström (Lysator)
Previous text:
pike-devel@lists.lysator.liu.se