[vlc-devel] [vlc-commits] mjpeg: fix leak

[Rémi Denis-Courmont]

Le maanantaina 8. kesäkuuta 2020, 14.01.40 EEST Steve Lhomme a écrit :
> On 2020-06-08 12:42, Rémi Denis-Courmont wrote:
> > Le maanantaina 8. kesäkuuta 2020, 13.34.19 EEST Steve Lhomme a écrit :
> >> On 2020-06-08 12:11, Rémi Denis-Courmont wrote:
> >>> Le maanantaina 8. kesäkuuta 2020, 12.47.17 EEST Steve Lhomme a écrit :
> >>>> This broke the Raspbian build because you're giving a demux_t* where a
> >>>> vlc_object_t* is expected. You need to use VLC_OBJECT().
> >>> 
> >>> No it does not.
> >> 
> >> It does not what ???
> > 
> > This patch does not break the build on Debian and derivatives.
> > I tested that much before pushing it.
> 
> You didn't check the warning either.

And? If I have to choose between a hard-to-spot memory leak and a harmless and 
trivially-fixable warning, I'll pick the later any day. Not to deny that 
warnings should be avoided/fixed.

I did not see the warning because I had to rebase across the poll.h patch, 
which caused full rebuilds. That's mandatory review process plus law of 
unintended consequences.

> And judging by the activity this week-end I can tell you're not doing
> too many checks when pushing your code:
> https://code.videolan.org/videolan/vlc/pipelines/

You know what? Screw you. I did test the stuff.

Of course, the Windows build has been broken for months here due to D3D11 
stuff, so I can't fully test Windows. Should I guess who broke that?

(...)
> I do not want dirty pointers on the builds I maintain. I will do the
> same for the UWP version.

That's your problem.

You were told not to do this. You were told that we had already discussed and 
experienced it. You ignored those warnings.

By my moral values, that's your responsibility. In fact, it's even your fault.

> You may push some dirty code but don't be surprised when people complain.

See if I care.

-- 
レミ・デニ-クールモン
http://www.remlab.net/