On Mar 20, 2012, at 6:55 AM, Michael Matz wrote: > Actually you did. I've tried yesterday to come up with a text that would > do the same (because I agree with you that deleting the assert changes > the spec of the function,
The spec of the function is the text above the definition of the function, coupled with the information in the .texi file, would you agree? If so, could you please quote the text of the spec which would be violated by removing the assert? Could you please give a specific value with which we could talk about that shows a violation of the spec. My position is simple, the spec is what is above the definition and the .texi files, and the stuff inside the definition are interesting implementation details of that spec, which _never_ modify the spec. My position is that 0 is a value which the spec defines, and for which we assert. Please quote the line from the spec that defines what we do in that case. I've never seen anyone quote such a line. To support your position, I will insist on a direct quote from the spec. > simply because the assert _is_ part of the spec of the function), and my > attempt was _much_ worse than yours, so I didn't send it :) If you consider Eiffel, the pre and post condition on a function are indeed part of the spec of the function. But, when they are wrong and need to be fixed, you can't argue that since the spec says if I is 42, abort, then trivially, we can't fix the spec because the spec says that if I is 42, we abort. To back the position that spec must not be changed, you need to explain at least one thing for which the wrong thing will happen if the spec did change. If you want to go down that path, you will need to furnish one example where badness happens with 0, not 2, not 3, but 0. If you can't do that, you loose. If you can, love to hear it. Now, if you cite a buggy piece of software that does the wrong thing as support, I won't be swayed, I will concede the fact gcc has bugs and those bugs should be fixed, it always has, and always will. See my other post for examples of existing bugs in gcc that are not protected by the assert. I am sympathetic to preferring asserts over wrong code gen, so, I'd be willing to fix all the buggy routines or make them assert, before we loose the assert. In that case, I'd really prefer a list of concrete places to fix. An unbonded idea that the entire rest of the compiler needs fixing is, well, doesn't bode well for incremental forward progress. Given just how buggy it is, personally, I don't see the problem in just declaring that OI is completely buggy, and move on.
