Prev: o.k. to use boolean expression as array index?
Next: linktime error for function overloads in template class when library is a dynamic library
From: Herb Sutter on 23 Mar 2010 20:40
On Sat, 20 Mar 2010 05:32:19 CST, Joshua Maurice
<joshuamaurice(a)gmail.com> wrote:
>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
ETA yet.

For status on progress and other information, please watch the Connect
bug report here:

https://connect.microsoft.com/VisualStudio/feedback/details/336316/

Thanks,

Herb


---
Herb Sutter (herbsutter.wordpress.com) (www.gotw.ca)

Convener, SC22/WG21 (C++) (www.gotw.ca/iso)
Architect, Visual C++ (www.gotw.ca/microsoft)

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: James Kanze on 23 Mar 2010 20:43
On Mar 20, 7:17 am, "Balog Pal" <p...(a)lib.hu> wrote:
> "Edward Diener" <eldie...(a)tropicsoft.invalid>>

> These errors are in the "nuisance" category. Compile fails,
> so you're forced some workaround. The one OP mentioned is in
> "danger" category -- the code compiles silently with incorrect
> code generation.

All compilers I know of have some bugs in that category as well.
It's true that they generally agree to fix them as soon as
possible when they are pointed out (for some definition of "as
soon as possible").

Since I'm apparently at the source of this, I'd like to
relativize it somewhat:

-- The bug takes a very particular combination of conditions to
appear; VC++ doesn't just drop destructors at random.

-- IMHO, in most application domains, that combination of
conditions simply won't appear, unless you're coding so
badly that nothing is going to work anyway.

On the other hand:

-- There are a few domains, particularly where complex
numerical analysis is involved (but possibly others as well)
where it can reasonably appear; it won't ever appear in code
I write, because my style (usually SESE) will never create
the particular combination of conditions, but the code where
I did find it wasn't unreasonable, and

-- It cost me three weeks to track down, three weeks of my
time, paid for by my employer (which means that a new
feature which we should currently be testing hasn't been
implemented yet).

It is, obviously, that last point which made me bring the issue
up to begin with. I don't care if it's one in a million, if I
happen to be that one. (Similarly, I don't care if its 999999
in a million, if I'm the one exception.)

Anyway, I can understand Microsoft's original decision, even if
I don't agree with it, and I'm thankful for Herb's intervention
now. (Now how do I get him to go about intervening on the two
other bugs I've encountered. Particularly since one involves
something that I don't think is even officially supported.)

[...]
> Guess everyone around here agrees the perfect symmetry of
> ctor/dtor calls is fundamental in C++ and any code we write
> just takes it as granted.

Only the younger generation:-). I can remember a time when
almost all compilers I used had some problems in this regard.
(G++ 1.49 generated the destructor calls at the end of the
block. Immediately behind the ret instruction it generated if
there was a return statement in the block:-).)

> Seems folks at M$ have different thoughts and just plant
> breaking bug in the optimizer -- ant then refuse to correct
> it. In 2 years, then decide to not fix it at all. To me that
> sounds outrageous and is ground to drop using MS compilers.

If you refuse to use a compiler with any bugs, then you won't be
doing much C++.

> O, Murphy can't be ignored, so bugs may be in the release, but
> I expect them gone after discovery. Suggesting "workaround"
> for the few weeks is okay, but thinking actual programmers
> shall stop using locals in a loop -- or start to count returns
> in functions? Hell no.

First, it only occurs if you return the local. Conditionally.
And there is no other return statement in the function. I don't
think that that's a common case. It does occur, obviously
(since I encountered it), but I don't think it would ever occur
naturally in code implementing, say, a compiler. Which
doubtlessly explains why the compiler team at Microsoft thought
it was rare enough to be ignored.

[...]
> Maybe a petition signed by many ACCU members (and other C++
> users) could create some force.

In the case of large companies, like Microsoft and Sun, all it
takes is a big enough customer. Presumably, no large customer
had complained. If Herb didn't know me, and intervene
personally in the problem, they probably wouldn't have reacted.
(On the other hand, if the work-around hadn't been so simple, my
bosses might have had purchasing intervene, and we're probably
a big enough customer to get some reaction.) This isn't
particular to Microsoft---it's just the way things are (and I've
had similar experiences with Sun: when my one-man firm posted an
error, it was noted; when my customer, who was Sun's largest
account in Europe that the time, complained, one week later
there were three engineers from California on site to find out
what the problem was.)

> In the last decade, I several times wrote in differnt foruns
> addressing the usual MS-bashing and claims about poor quality,
> that it mostly roots in the 90's and the company IMO changed
> for the right track around 2000 -- certainly the cleanup takes
> time but the will is there, and resources are used for good.

Like most companies, they're mixed. If you use them, you take
the bad with the good.

--
James Kanze

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Balog Pal on 24 Mar 2010 15:13
"Herb Sutter" <herb.sutter(a)gmail.com>
>>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
> ETA yet.

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:

http://news.bbc.co.uk/2/hi/technology/7824939.stm

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
collecting $200...).

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
summed.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2
Prev: o.k. to use boolean expression as array index?
Next: linktime error for function overloads in template class when library is a dynamic library