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? [...] -- Clément B. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
