On Mon, 10 Apr 2017 09:28:06 +0200 Clément Bœsch <u...@pkh.me> wrote:
> On Mon, Apr 10, 2017 at 08:53:09AM +0200, wm4 wrote: > > On Mon, 10 Apr 2017 07:54:41 +0200 > > Clément Bœsch <u...@pkh.me> wrote: > > > > > On Mon, Apr 10, 2017 at 03:51:40AM +0200, Michael Niedermayer wrote: > > > > On Sun, Apr 09, 2017 at 06:46:51PM +0200, Clément Bœsch wrote: > > > > > Toolchains which target debugging are meaningless with stripping and > > > > > toolchains which target memory tracking are meaningless with memory > > > > > pollution. > > > > > --- > > > > > configure | 8 ++++++++ > > > > > 1 file changed, 8 insertions(+) > > > > > > > > memory_poisoning is not enabled by default in configure > > > > > > > > > > but it is enabled by the fate configure, so if you create a FATE instance > > > with valgrind, you may forget that memory-poisoning is enabled and make it > > > useless for uninitialized memory without realizing. > > > > I love it when such questionable debugging features interfere with real > > debugging tools. > > Well, it's a debugging "tool". This is another debate, but if people > prefer that I drop the feature, it's fine with me. I introduced it a while > ago believing it would help spotting simple cases of uninitialized memory. > I don't know if it had any practical use cases yet. > I'd argue against the feature, because the same can be achieved with LD_PRELOADING something that replaces malloc. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
