On Fri, Dec 16, 2016 at 01:48:16PM +1100, Matt Oliver wrote: > Recently we have again received several patches that are trying to add > workarounds for ffmpegs use of DCE. This is not the first time this has > happened and wont be the last until a decision is made about the use of > DCE. So I think its time that we made a official decision on the use of > DCE. This is of course something that should be properly agreed upon by > developers going forward as different people have different opinions on the > matter so to help assist this I will summaries all of the previously made > arguments from both sides of the discussion. > > For DCE: > 1) Ends up with a horrible mess of ifdefs. > 2) Disabled parts of code will not be checked for syntax. > > Against DCE: > 3) DCE is not actually specified in the C specification. So compilers are > actually being 100% compliant by not supporting it and should not be > expected to change just for ffmpegs use case. > 4) Breaks debug and lto builds on msvc. > 5) Breaks debug and lto builds on icl. > 6) Issues with lto with Clang and Gold. > 7) Other unspecified issues with debug builds > > Rebuttals against above arguments: > 8) There are already 3961 #ifs(not including header guards) in the code so > there is already a lot of code that doesn't use DCE. (In response to #1 for > DCE). > 9) Avoiding #ifdefs is a personal opinion as to whether they are ugly or > not (some prefer ifdefs as IDEs will correctly highlight disabled > sections). Someones personal preference for what looks better should not be > justification to break supported configurations/compilers. (In response to > #1 for DCE). > 10) There is --enable-random which is supposed to be used to find > configurations that don't compile. (in response to #2 for DCE). > 11) Just because something compiles does not mean that it actually works, > relying on just syntax checking is dangerous as it gives false security as > the code is not actually being tested. (in response to #2 for DCE) > 12) There are numerous FATE tests that should find all the configuration > errors. (in response to #2 for DCE) > 12) MSVC is broken and we shouldn't support it so Microsoft are forced to > fix it (in response to #4 against DCE) - This point is countermanded by #3 > against DCE and reported issues with other compilers as well. > > > Most of the above points were taken from peoples posts in the following > mailing list thread: > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194115.html > > Its my personal opinion that DCE should be removed from the code but this > is something I am aware will require a developer consensus and perhaps even > a vote. Stating something is broken is one thing so I will also put forward > a solution in that if it is agreed upon to remove DCE usage then I will > spend the time and effort to go through the existing code base and replace > DCE with appropriate #ifs.
how hard would it be to write a preprocessor like tool to convert all if (ARCH/HAVE/CONFIG_SYMBOL ...) to #if ? If that was doable and if someone wants to do it then this would put another option on the table [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
