Robert Dewar wrote:
>> I don't see why that demand would prevent register allocation. Maybe
>> you can explain that to me.
> Probably the best thing is to refer you to a good compiler book, such
> as the dragon book. It really is necessary to understand compiler
> technology to understand this kin
Seongbae Park wrote:
>> Seongbae, didn't you say that Sun's compiler uses the fact that signed
>> overflow is undefined when performing optimizations?
> Correct.
I stand corrected. I didn't read the fine print in
http://docs.sun.com/source/806-3568/ncg_compliance.html
that said "unless you us
Robert Dewar wrote:
>> Making a call here before knowing this is not sensible. In fact,
>> I'm tempted to argue that it is generally a bad idea to do
>> optimizations that lead to the same expression being evaluated to
>> different results without making the user explicitly request them.
> People
Joe Buck wrote:
>> But if the gcc user base prefers performance over security, and you are
>> willing to go with them, they might get what they deserve.
> You continue to confidently assert, without any backup, that loop
> unrolling that assumes overflow does not occur has a negative security
> imp
Mark Mitchell wrote:
> In this specific case, we know there is a significant performance
> impact, and we know that performance is very important to both the
> existing and potential GCC user base, so I think that making the
> compiler more aggressive at -O2 is sensible.
Whether or not that is sen
Richard Kenner wrote:
> I agree with all the arguments about legacy code, but I'm much less
> tolerant of such arguments for NEW code.
Thanks for clarification. I think legacy code is the big problem here
anyways.
Andreas
Steven Bosscher wrote:
>> "It's not my fault if people write buggy software" is a lame excuse
>> for sloppy engineering on the part of gcc.
> So basically you're saying gcc developers should compensate for other
> people's sloppy engineering? ;-)
This might be a little exaggerated, but there's ce
Richard Kenner wrote:
> I was addressing the claim that we allegedly have people writing security-
> and/or safety-critical software who don't understand the semantics of that
> language as they relate to safety and security (namely, what overflows do).
> That's a serious problem. Of course, there
Ian Lance Taylor wrote:
>> You have just seen somebody who can be considered an expert in
>> matters of writing C sofware come up with a check that looks
>> correct, but is broken under current gcc semantics. That should
>> make you think.
> I'm not entirely unsympathetic to your arguments, but
Daniel Berlin wrote:
> And you think that somehow defining it (which the definition people
> seem to favor would be to make it wrapping) ameliorates any of these
> concerns?
Yes, absolutely. There is a difference between well-defined and
understood semantics on one hand, and undefined and probabl
Ian Lance Taylor wrote:
> Consider code along these lines:
>
> struct s { int len; char* p; };
>
> inline char
> bar (struct s *sp, int n)
> {
> if (n < 0)
> abort ();
> if (n > sp->len)
> abort ();
> return sp->p[n];
> }
>
> void
> foo (struct s *sp, int n)
> {
> int len = sp->l
Joe Buck wrote:
> You appear to mistakenly believe that wrapping around on overflow is a
> more secure option. It might be, but it usually is not. There are many
> CERT security flaws involving integer overflow; the fact that they are
> security bugs has nothing to do with the way gcc generates c
Ian Lance Taylor wrote:
> I just want to report that I have a working patch to generate warnings
> every time gcc modifies code relying on the fact that signed overflow
> is undefined, except for cases where signed loop indexes are assumed
> to not wrap around. I plan to start submitting this patc
Dear compiler hackers,
I feel compelled to revisit a topic that has already been extensively
discussed on this mailing list, unfortunately with an outcome that is
highly dangerous to the security of about any existing system compiled
with gcc in the world.
It is my fear that the existing behaviou
14 matches
Mail list logo