[FFmpeg-devel] [PATCH 3/3] avcodec/aacpsdsp_template: Fixes integer overflow in ps_add_squares_c()

[wm4]

On Mon, 10 Jul 2017 23:10:35 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Mon, Jul 10, 2017 at 10:37:46AM +0200, wm4 wrote:
> > On Sun, 9 Jul 2017 22:03:21 +0200
> > Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> >   
> > > On 09.07.2017, at 16:08, "Ronald S. Bultje" <rsbultje at gmail.com> wrote:  
> > > > Hi,
> > > > 
> > > > On Sun, Jul 9, 2017 at 4:39 AM, Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> > > > wrote:
> > > >     
> > > >> On 09.07.2017, at 02:52, "Ronald S. Bultje" <rsbultje at gmail.com> wrote:    
> > > >>> On Sat, Jul 8, 2017 at 5:17 PM, Michael Niedermayer    
> > > >> <michael at niedermayer.cc>    
> > > >>> wrote:
> > > >>>     
> > > >>>> 
> > > >>>> Does anyone object to this patch ?
> > > >>>> Or does anyone have a better idea on how to fix this ?
> > > >>>> if not id like to apply it    
> > > >>> 
> > > >>> 
> > > >>> I think Rostislav's point is: why fix it, if it can only happen with
> > > >>> corrupt input? The before and after situation is identical: garbage in,
> > > >>> garbage out. If the compiler does funny things that makes the garbage
> > > >>> slightly differently bad, is that really so devilishly bad? It's still
> > > >>> garbage. Is anything improved by this?    
> > > >> 
> > > >> The way C works, you MUST assume any undefined behaviour can at any point
> > > >> [..] become exploitable.[..] If you don't like that, C is the wrong
> > > >> language to use.    
> > > > 
> > > > 
> > > > I think I've read "the boy who cried wolf" a few too many times to my kids,
> > > > but the form of this discussion is currently too polarizing/political for
> > > > my taste.    
> > > 
> > > That is my reading of the C standard, is that political or even just controversial?
> > > I mean of course you can ignore standards (see MPEG-4 ASP, and in some ways that was actually fairly reasonable thing to do at the time), and I don't fix every undefined behaviour case in my code when I can't think of any reasonable solution.
> > > So there is a cost-benefit discussion in principle.
> > > I believe the cost of not fixing undefined behaviour, just by virtue of going outside what the standard guarantees should be considered fairly high.
> > > That is an opinion, but is there any disagreement that undefined behaviour is at least an issue of some degree?
> > > If we can agree on that, then the question would only be how much effort/code ugliness is reasonable.
> > > There is also the point (which I hope I mentioned in the parts cut out) that just making sure that these cases are not already exploitable right now with the current compiler can in many cases be quite a pain (and does not have tool support), so I think fixing it would often be the lowest-effort method.  
> > 
> > The controversial thing is actually the SUINT nonsense. A type is
> > either signed or unsigned, but not both incompletely intransparent  
> 
> > ways. Michael keeps adding them even though many are against it.   
> 
> It is extreemly rude from you to make this claim.
> When in fact i try my best to respect every maitainer and authors
> preferrance and never add it when people object.

Do you deny that you keep sending patches that add SUINT usage? Do you
deny that you know that certain people don't like SUINT?