Slashdot Mirror
Chromium Being Ported To VC++, Scrubbed of Compiler Bugs
jones_supa writes: Moving a big software project to a new compiler can be a lot of work, and few projects are bigger than the Chromium web browser. In addition to the main Chromium repository, which includes all of WebKit, there are over a hundred other open-source projects which Chromium incorporates by reference, totaling more than 48,000 C/C++ files and 40,000 header files. As of March 11th, Chromium has switched to Visual C++ 2015, and it doesn't look like it's looking back. The tracking bug for this effort currently has over 330 comments on it, with contributions from dozens of developers. Bruce Dawson has written an interesting showcase of some VC++ compiler bugs that the process has uncovered. His job was to investigate them, come up with a minimal reproduce case, and report them to Microsoft. The Google and Microsoft teams get praise for an excellent symbiotic relationship, and the compiler bugs have been fixed quickly by the Visual Studio team.
As near as I can tell they switched the Windows build from VC++ old version to VC++ new version. Because:
- Improved C++11/14 support /analyze checked rolled into main compile
- Security improvements
- Some
- Possibly some improved support for "cloud" builds
Just their principal Windows build environment changed in March 2016 from VS 2013 (still supported) to VS 2015. This is no news... really.
I have ported around thru a bunch of different compilers over the years a few codebases.
I can count on one hand the number of VC compiler bugs I have come across. They are seriously nasty to root out as my assumption is the compiler is usually right. MS usually had it fixed in under a week with a hotfix. When you buy visual studio you get some fairly top notch support.
Now the other bugs. I lost count of. All of those were usually a misunderstanding of how C/C++ works. A few cases were like you said GCC-isms vs VC-isms. Where the code would do one thing on one compiler vs the other. Many times it was we were doing something that was not quite in spec anyway and it was just easier to toss out the silly code and re-write that small bit.
Also most of the time the big thing to keep in mind is the standard libraries are not the same across platforms. Take little old printf and scanf. That is C 150 sort of stuff you learn. Yet that thing is a land mine in pretty much all compiler suites. Then it acts differently on all of them (things like does %hhu work with this one or not, or it works with printf but not scanf sort of junk). Those two functions are a first class ticket to buffer overruns and underruns. They are all getting better on agreeing with things should do. But it is taking time.
Another fun gotcha between compilers is padding. Some do 16 bytes some do 8. Not a big deal right? Right up until the point you want to tear it apart and give that info to some other process. That may or may not be written with the same padding. So dense pack right? That ends up in memory alignment hell. x86 is fairly forgiving on that. ARM not so much.
Usually if I get it down to one compiler does X and the other does Y I abstract it. I abstract that small bit into its own file and then just switch out the files at build time or sometimes a #define but try not to do that can be confusing (whichever way is more clear I do).
Also most optimizer compiler bugs come down to you passing in the same memory space as two different parameters into a function. Dont do that.
>"As of March 11th, Chromium has switched to Visual C++ 2015..."
This should have been written as: ..."
"As of March 11th, WINDOWS Chromium build has switched supported compilers FROM Visual C++ 2013 TO Visual C++ 2015
This has nothing to do with OSX or linux builds and is not that much important news.