Hi, On Mon, Oct 3, 2016 at 4:11 PM, Clément Bœsch <u...@pkh.me> wrote:
> On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote: > > Le duodi 12 vendémiaire, an CCXXV, u-9...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
