[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)
tempn at mi.rr.com
Mon Oct 3 20:07:59 EEST 2016
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
> 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
he wrote musl because everyone hated glibc.
i contacted both him and even mike melanson (vp3 decoder author)
>* 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!
More information about the ffmpeg-devel