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.
Can't see anything but your reflection..
This comment was written with the intention to opt out of advertising.
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
...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....
That's a lot of files for a single, relatively trivial application..
All compilers have 'weird bugs and stuff' - staying with compilers 'that are well support across all platforms' is another matter altogether. I'm not sure why you are asserting the fact that VC++ has bugs - your text reads as if you are trying to convey it's the only compiler that does contain bugs, therefore you can't fathom as to why on earth a development team would move from one dev platform to another because of the bugs. Because it's Microsoft, it must be shit right? That's what you're saying?
What, from Borland Turbo C++ 3.0?
From thesecond link it seems as if they were upgrading from VC++ 2013
I am Slashdot. Are you Slashdot as well?
Just their principal Windows build environment changed in March 2016 from VS 2013 (still supported) to VS 2015. This is no news... really.
The summary, especially the title, omitted a really important detail: it's not that they are porting it to VC++, it's that they are making it work with VC++ *2015*.
IOW they apparently already had the build working with an earlier version of VC++, and this is all about them changing things to work with this newer version of VC++.
A lot of times compiler bugs fall into categories that aren't bugs at all. 1. Stuff that people think is standard C, but it's really a GCC-ism. 2. Stuff people didn't know about standard C, such as the order of argument evaluation being unspecified. 3. Default settings on one compiler being forgiving and/or handling uninitialized variables in a particular way, and the other compiler not being so forgiving.
I can't remember who said so first, but it's generally given that the first people to scream "compiler bug" are usually doing something wrong with their code. I wouldn't be surprised if a lot of the people in academia who you say write shitty software are doing that kind of thing. "Oh! compiler bug!" Nope. You just had something that "worked on my machine" and now it doesn't.
Google people have been investing a lot of time and effort over the last year or so in Windows support for clang. Interestingly, Microsoft has also been contributing and has some odd combinations (MSVC++ front end with LLVM back end and Clang front end with MSVC++ back end) working.
I am TheRaven on Soylent News
I don't know, GCC has a lot of quirks that make it a pretty poor standard to code by. By making it compile with VC++ they open the door to elminiting the GCC workarounds, and possibly open the door for more platforms. As someone who has tried to port software in the past, GCC is really a thorn in my side.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
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.
So Microsoft tools are so difficult to use across different tool versions that it becomes a news story when someone manages to upgrade?
Just because we let you cut the lawn doesn't make it yours sonny. :)
Insert pithy comment here.
Another benefit is using multiple compilers helps find tricky bugs due to assumptions in the programming language.
Enabling all warnings can easily help find those parts of code that are iffy but look normal, but the compiler knows something may be an issue. Using a different compiler produces a different set of messages that can reveal all sorts of bugs.
Well, Chrome has been warning XP users that support for XP is stopping "shortly". The stupid thing is, the "Learn more" link the pop up shows leads to the "Download Chrome" page instead of a page explaining why. So yes, they're stopping support for XP and VIsta, but they aren't telling you why, other than to "Download Chrome".