On Mon, 3 Oct 2016 17:01:12 +0200 u-9...@aetey.se wrote: > 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".
musl could also choose to abandon its incredibly "clever" hack (that makes almost everyone who sees it go "WTF"), and, as was pointed our on IRC, probably increase the efficiency and readability of the code in question. Yes, musl is technically in the right, but only technically. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
