Re: Microsoft chooses to leave C++ compiler broken
"Herb Sutter" <firstname.lastname@example.org>
As a reply to Herb Sutter, even if the code required to trigger the
bug was some obscure little thing (which it is not), people can still
hit it in the real world. My company generates C++ code from a very
limited modeling language to allow object serialization between C++,
xml, and Java. Imagine what wonderful little code paths in the
optimizer could result from code generation on code generation?
I (and we) agree that this is fundamental, and sorry that this bug
report did slip through the cracks.
FYI, the team has continued to investigate this over the weekend and
we've decided to develop a QFE (Quick Fix Engineering = hot patch) for
this because we believe it's a high priority bug. The patch will be
developed and made available for both VS 2010 (about to ship) and VS
2008. The patch should be available in the coming weeks, no specific
I am glad to hear that.
Will there be a process-level fix too, from the "lessions learned"?
When I find a bug that went through the QA process and needs such revision
later, I check the cases for possible "kind of" issuses. If I were there in
this case I'd run query on the bug database for (closure = no-fix && impact
= incorrect code generation).
If there are more, I guess the cost if issuing a hotfix for multiple is not
much more that of a single issue -- and balanced by trust of custiomers.
I read the link, quoting
"As previously noted, this was a mistake and the recent discussions and
feedback about this decision on this and other channels have been
illuminating, to say the least. I will certainly not forget the lessons
learned here and will apply them in the future. "
I hope the conlusion that "estimating probablility on certain classes of
issues is just a bad idea" is among them.
A year ago I read this:
announcing that major players agreed that certain kind of errors are not
supposed to exist in released products. Microsoft is among them. Good
stuff if actually meant. At least my interpretation of it suggests that it a
company finds a bug falling in one of the listed category, the rest of
evaluation can be scrapped and go directly to fix, (not passing Go, not
The errors on the list are of a generic nature, for specific products I'd
expect more items with similar treating. And experience should have
proven that better quality pays off, while keeping bugs in the codebase
untreated is actually expensive, as soon as all the impact is correctly
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]