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

[u-h8zb at aetey.se]

Hello Ronald,

On Sat, Oct 01, 2016 at 03:11:38PM -0400, Ronald S. Bultje wrote:
> I'm not sure we want to go down the rabbit hole of allowing any code to be
> executed inside frame en/decoding routines. Historically, IIRC, we have
> disallowed float in user callbacks like request_frame also.
> 
> Why does musl malloc require float? This is a real question. I can't think
> of any reason why you'd want this.

Taking the question for what it is, I have already answered - because
it make sence for the C library implementation and functioning.

We are not talking about what you and me "would like inside a standard
library" but whether we can rely on the specified interfaces. The
malloc() interface was apparently misunderstood as a promise to never
do float. There is no such promise.

If ffmpeg depends on the implementation details behind the abstraction
of the standard C library, then it is not portable. This would be
regrettable.

> Historically, IIRC, we have
> disallowed float in user callbacks like request_frame also.

It is fine to disallow calling any C library routines which can do
floats. Then this by definition implies the majority (all?) of the C
library routines, because the user has no power over its internals.

We can not do anything to this fact, if we do not break the C library
abstraction by postulating implementation details or redefining
the interfaces with extra non-standard contraints.

I would of course instead prefer keeping the assembler code harmless
to the FPU and hope this is not overly expensive.

If this is a real hit against efficiency (frankly, it should not be
_that_ important, mmx is a technology of the past anyway) it might be
worth taking up on the musl mailing list and see what its developers say.

Regards,
Rune