Le sextidi 26 frimaire, an CCXXV, Matt Oliver a écrit : > For DCE: I do not care much about DCE one way or the other, but I do care about valid arguments.
> 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. That is true in principle, IF the project decides it wants to be standard C. This is an option, but not the only one. For example, the code would break if ints were 16 bits, thus we require POSIX, not only C. It would also break if intXX_t were not available, thus we require optional parts of the C standard. Similarly, the project is perfectly allowed to require non-standard extensions. "If your compiler does not do DCE, we do not support it, sorry, do it yourself." And if somebody argues about the "standard" / "non-standard" thingie, I create the Cigaes Standardization Organization and publish the Cigae C Standard, where DCE is specified. > 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). There are unavoidable cases, that does not make it ok for the avoidable cases. > 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). Someone's personal preferences affect their willingness to work on the project. Since the project is perpetually short on manpower, this is a very serious issue. > 10) There is --enable-random which is supposed to be used to find > configurations that don't compile. (in response to #2 for DCE). --enale-random is useful for checking problems caused by optional features that are usually disabled: A depends on B but it is not stated in configure, thus breaking if B is disabled but A enabled. The benefits of DCE are in the other directions: testing (partially, see below) features that are usually disabled. For example, I develop on Linux, the windows and mac features are always disabled, but I still have a safety net preventing me from the easiest breakages. > 11) Just because something compiles does not mean that it actually works, Yes, but if it does not compile, then it can not work. > 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) It must be eventually tested. But catching errors earlier is better, it spares developer time. This argument is "it is not perfect, therefore it worthless". Well, your bank account is not perfect, it does not contain all the money in the world. Is it worthless? If you think so, feel free to give it to me :) > 12) There are numerous FATE tests that should find all the configuration > errors. (in response to #2 for DCE) Please tell me how I can run the FATE instances for other platforms than mine BEFORE pushing patches. > 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. Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
