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

[compn]

On Mon, 3 Oct 2016 12:45:13 +0200
u-9iep at aetey.se wrote:

> > > http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n114
> > 
> > Urgh. This is even worse than I imagined. FFmpeg is using undefined
> > behaviours by calling it without resetting the state, but this is
> > also completely undefined behaviour on their side.
> 
> I feel a duty to remind, in the most positive and friendly tone:
> 
> 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.

ehe, well...... do your homework before assuming things. ;)

rich felker , who wrote musl, was an mplayer and ffmpeg? developer
actually.

he wrote musl because everyone hated glibc.

i contacted both him and even mike melanson (vp3 decoder author)


mikes reply:

>* I didn't write any VP3 MMX (or other SIMD), so I can't be of much
>  immediate help, even if I did have perfect recall of the code.
>  However, I invite you to run 'git blame' on the vp3 code and see how
>  many of my non-comment lines still persist.

rich felker musl reply:

> [23:46] <dalias> yes they're violating the x86 abi
> [23:46] <dalias> at function call time the x87 floating point stack
> has to be empty (and thus in x87 mode, not mmx mode)
> [23:47] <dalias> you can't call external functions while in mmx state

i dont doubt its a bug in vp3 that needs to be rewritten.
but we also go to extreme lengths to blame others... ;D

musl could handle it better sure, but should they really write a full
c-checker into their lib? would make it as bloated as glibc!

-compn