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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel