On Fri, Jul 8, 2011 at 02:35, Martin <f...@mfriebe.de> wrote: > On 07/07/2011 16:27, Alexander Klenin wrote: >> >> 1) That the code you posted would work quite correctly if "const >> string" is fixed, >> including all the optimizations you are suggesting in the rest of >> your message. > > No. > > As I said: IF the result of constant expressions like "s[a] = '<'" are > cached (in future) depending on optimization level, then it breaks.
Well, maybe you should run the code and see for youself -- I do not know how to explain this in even more detail. It will *only* break due to the current optimization bug. Remove the bug, and no breakage is possible, with or without caching you describe. Even now, if you ensure refcount>1, no breakage is possible. > The 2nd evaluation, of this expression without optimization returns a > different result from the 1st evaluation. (It may be that the example would > need updating, but there is code where this can happen, including if > ref-counting was done) > > So depending on the 2nd evaluation being done, or cached (future > optimization) the program flow differs. It only differs now due to the current optimization bug. Remove the bug, and the code will stop breaking. > Code which behaves unpredictable is broken. Exactly. This is the problem I hope to fix. -- Alexander S. Klenin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
