| > Let me know if there is a library that is blocked that we don't know about and I will see what we can do. To reiterate what another commenter wrote, the question is not "what libraries cannot build?" but: - what libraries have unpleasant hacks and workarounds sitting in their code-base? - how much of an extra burden is imposed by having to accommodate MSVC, since its support for C99 is partial? I'm happy that MSVC has been adding a lot of C99 features. But what will really make the difference is when it can say "supports C99", without major caveats. Because then we'll be able to write cross-platform libraries that target C99 without having to constantly tend to MSVC to check that we haven't broken the build on your platform. Or worse, made a design choice in API or implementation that requires a C99 feature not supported by MSVC! I was excited to see C99 support in MSVC2013. I tried compiling my code-base against it. But then I ran into this bug: https://bellecrazysnail.wordpress.com/2013/11/14/some-though... You can declare variables in the middle of blocks! As long as it's not a struct variable declared right after a brace-less if/while. Umm.... This is an example of having to "tend" to MSVC. So if you want to gain trust, the question should not be: "who out there is still broken?" It should be "how can we make our compiler Just Work, instead of being something that everyone else has to accommodate all the time?" Apple has done it with Clang. Surely Microsoft can do it with MSVC. |