On 8/5/2013 6:48 AM, Diego Biurrun wrote:
Before we start littering our code with workarounds for such issues we should indeed rule out that it's a bug. If it is a bug, the bug should be reported and hopefully get fixed, obviating the need for workarounds.
After talking with some developers, it seems that most of the patch is unneeded -- cygwin does not define _WIN32, so checking defined(_WIN32) && !defined(__CYGWIN__) is a tautology. Confirmed by doing an #ifdef + #error test. This only leaves the commandline parsing, which is always done regardless of whether it's actually needed or not; it's conditioned on whether the function exists and is accessible.
There is no windows platform released in the past 13 years that *doesn't* have that function (all in the past 20 years if you link with unicows), so the test always passes (even in cygwin), leading to the bad behavior. The special commandline parsing should be conditioned on _WIN32 (instead of !defined(__CYGWIN__), or even HAVE_COMMANDLINETOARGVW, unless you intend to support win9x). Should I write the patch for that?
Also, according to http://cygwin.com/ml/cygwin/2013-07/msg00343.html, that the GetCommandLineW call used to return the arguments like on mingw was a bug to begin with.
PS: A mingw64 developer also mentions that _WIN32 is not a "this is windows" define, but a "this is window's libc" define: windows.h was corrected to not define _WIN32 either; it's defined by the compiler. Code that builds on Cygwin is supposed to pretend (and believe) that it's linux minus syscalls; parts of the code that really do intend to use the winapi even inside Cygwin is supposed to use defined(_WIN32) || defined(__CYGWIN__).
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
