2013/11/6 Michael Matz <m...@suse.de>: > Hi, > > On Wed, 6 Nov 2013, Ilya Enkovich wrote: > >> >>> Well, but clearly you can see that bounds for p == NULL are >> >>> useless and thus there is no problem with the transform. >> >> >> >> This example just demonstrates the issue. I may use some var's address >> >> in comparison with the similar result. And value does not always allow >> >> to determine bounds, because pointers with the same value may have >> >> different bounds. >> > >> > Some vars address can be used for better bounds deriving though. >> > Well, it clearly shows it's a "get me good results" issue and not >> > a correctness issue. And for "good results" you trade in missed >> > general optimizations. That doesn't sound very good to me. >> >> That is definitely a correctness issue. Compiler cannot assume bounds >> by pointer value ignoring bounds passed to the function. > > Of course they can. They assume "unbounded" for unknown bounds and emit > correct code. It's merely more conservative than you'd like (as the > function got passed tighter bounds than unbounded), and hence no > correctness but a QoI problem.
Well, it depends on what we call 'correct' behavior for checker. I suppose that bound violation caught on -O0 and not caught on -O2 is a compiler issue. That is why I call it correctness issue. When you instrument your code you intentionally slow your program down to improve security. Compiler should have strong reason to behave contrary. Of course, there should be some trade off. But in this particular case I do not see why we should make pointer unchecked. If I just drop this patch and use undefined bounds in all cases arg_bnd call is optimized, I wont get any performance gain. Ilya > > > Ciao, > Michael.
