------- Comment #22 from pinskia at gcc dot gnu dot org 2007-01-17 17:42
-------
(In reply to comment #21)
> I DID NOT WRITE THE BROKEN CODE.
But you wrote the bug so I assumed you wrote it.
> Trying to trivialize the issue or insult me will not make it go away.
How about this has not changed since at least "January 24, 1994" (when 2.5.8
was released) so the decission about this code was made 13 years ago. What
does that say about new code since then?
> So, please tell me, which part of the argument in comment #9 were you unable
> to
> follow? I could try using less complicated words so you actually understand
> it
> this time around.
None. Just this decission was done a long long time ago before I even started
working on GCC.
> Guys, your obligation is not just to implement the C standard. Your
> obligation
> is also not to break apps that depend on you. And A LOT of apps are depending
> on you. When you broke the floating point accuracy, you made it opt-in
> (-ffast-math).
Actually -ffast-math breaks the C standard too so your argument here fails.
> When you added the aliasing breakage, you made it opt-in
> (-fstrict-aliasing).
I think we should not have made that optional but I was not around when that
decission was made. Also remember we had a release (2.95) where it was on and
then it had to be turned off by default (2.95.2) while people fixed there code
but while this optimization was on during that time.
And we do make this optimization optional with -fwrapv already so I don't see
where you argument is going to now.
> IIRC for that you also quoted some legalese from the
> standard at first, until people with more grounding in reality overruled you.
> And I'm going to keep this bug open until the same thing happens again for
> this
> issue.
Why this really should not be discussed in the bug but on the gcc@ mailing list
where all over discussions happen?
>
> You can't just potentially break of the free software in the world because you
> changed your mind about what liberty the C standard gives you. Grow up or
> move
> out of the way and let more responsible people handle our infrastructure.
Wait a minute, this optimization has been there since 1994, if new code in the
free software world has abused signed overflow like this, they were asking for
it.
>
> You know that the Ariane 5 rocket crashed (and could have killed people!)
> because of an int overflow?
And I showed you how to find an overflow before it happens and not after so
that argument is dead in the water.
> What if people die because you decided the C standard allows you to
> optimize away other people's security checks?
Again I showed you how to check for integer overflows before they happen
instead of after. You can teach other security people how to write that code.
> Again: IT DOES NOT MATTER WHAT THE C STANDARD SAYS. You broke code, people
> are
> suffering damage. Now revert it.
Revert what was done 13 years ago. Do you have a time machine, because I sure
had hoped so because I wantted to change what happened last year a little bit.
> The least you can do is make -fwrapv on by
> default.
It is default on languages which actually define the language that way.
> You would still have to make it actually work (I hear it's broken in
> some corner cases?), but that's another story.
It __WAS__ broken in a corner case but that already was fixed in 4.0.0.
Again there is no reason why this decussion should not be on gcc@ and not here.
I gave the correct way of writting overflow dection and if you don't like what
the C standard says, that is not my fault at all.
Remember GCC is also an optimizing compiler, if you want optimizations, you
need to follow the language which you are writting in closer instead of playing
it loose which is what is happening with both C and C++ in general.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
