Ronald, I sincerely appreciate that you are taking the effort to talk to me and explain your position.
Unfortunately in your messages you consistently ignored a crucial point and this is the last time I try to retell it: > On Mon, Oct 3, 2016 at 10:26 AM, <u-9...@aetey.se> wrote: > > What you are talking about is to ask Rich to modify musl to hide ffmpeg's > > non-compliance bug (which glibc/uclibc do by sheer luck but this may change > > any time). Which you answer with > - or we can just do what we do now and work with musl people to change > their code. Once again, musl has absolutely no reason to change its code, their code is well done and fully compliant. Their responsibility is rather to the contrary, _not_ to make changes which would hide sneaky bugs in applications. UB is a quite hideous bug. > If it turns out the first two are undoable and musl devs are > unwilling to do this, then we'll have to reconsider Carl's patch and call > musl on x86-32 unsupported, with a link to the relevant discussion to back You can not just "call musl on x86-32 unsupported", the only honest option is to document that ffmpeg is not compliant/safe. The problem is not in musl. Last time in this discussion let me try to make this fact understood: Musl merely showed you the problem and now you are suggesting to "document that the messenger with his bad news about our health is no longer welcome". > Again, this requires some time and thought. This sounds very reasonable. Best regards, Rune _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
