[FFmpeg-devel] Removing DCE

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161221/163a5705/attachment.sig>