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.

Reply via email to