Andrew Haley <[EMAIL PROTECTED]> writes: > If we make a change for openssh to allow this undefined behaviour, > then do we agree to keep it working or not? If we agree that we will, > then we have to at least add some test cases and we have to add some > internal documentation to gcc. If we don't agree to keep it working, > then even if we fix it today it may well break in the future.
As I tried to clarify in a separate message, I don't think we agree to keep it working. > I don't think we're doing the developers of openssh any favours by > compiling such code. Quite the reverse, IMO. This is, I suppose, the root of our disagreement. I believe that the people we hurt are not the developers, who presumably have enough sense to fix their code after they see the warning (if they don't, I don't care about them). The people we are hurting are the users, who discover that their existing third party code does not compile with the new compiler. Again, if we gained anything by not compiling their code, then I would be all for it. But in this case we do not gain anything. We're actually going to extra effort to break their code. To me this is related to the point I raised at the steering committee panel discussion (I know you weren't there): I think we are too casual about breaking existing working code. And, yes, the code may well break, or not work as expected in this version of the compiler or in some later version. After all, it is undefined. But we warned them it might break. That is all we need to do. We don't need to take the extra step to ensure that it definitely does break. I believe that is inappropriate. (Although I could imagine a gcc option -ftrap-on-undefined-behaviour, which some people would certainly find useful). Ian
