[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[Ronald S. Bultje]

Hi,

On Mon, Oct 3, 2016 at 4:11 PM, Clément Bœsch <u at pkh.me> wrote:

> On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote:
> > Le duodi 12 vendémiaire, an CCXXV, u-9iep at aetey.se a écrit :
> > > The author of the referred code acts in his actual area of competence
> > > (C libraries and standards).
> > >
> > > The comments here on the C library code and standard compliance come
> from
> > > developers having a different competence area (multimedia programming).
> > >
> > > As bright as the people here are, they land in a foreign area, which
> > > accidentally leads to statements like the above.
> >
> > I am sorry, but an appeal to authority will not cut it in front of real
> > arguments.
> >
> > The real argument here is: musl makes several assumptions about the
> > architecture and compiler (for example: that floats and ints have the
> same
> > endianness) that are not mandated by any standard. And although these
> > assumptions are very reasonable and widely respected, there will
> eventually
> > be an architecture or, more probably, a compiler, that will break them.
> >
> > FFmpeg does exactly the same.
> >
>
> TBH, having a set of supported architectures in a libc is much more legit
> than a set of supported libc in a multimedia framework IMO.
>
> We can mess as much as we want within our codebase wrt ABI violations, but
> I don't think it's reasonable to make random assumptions about libc (and
> others external libraries) implementations. It's way too risky. Even if we
> are able today to change musl implementation, seeing random floats usage
> in the many allocators out there doesn't look that surprising.
>
> Actually, if I was a valgrind developers, maybe I would do that on
> purpose...
>
> [...]
> > In this instance, we know the reason for FFmpeg: resetting the FPU state
> is
> > expensive, and this is speed-critical code.
>
> We have mallocs in inner loops of speed-critical? Really?


What code is speed critical? In an audio decoder (like a voice decoder)
where a decode call plays as many as a few tens of audio samples at best, I
would say that anything is speed critical, because once-per-frame isn't
that far off from once-per-sample in that case.

The bigger problem is that we're talking about malloc (actually, free,
according to cehoyos) here. But this could be any external/libc function.
We need emms before any libc call. That's ... Not just mallocs.

Ronald