and smiling... http://en.wikipedia.org/wiki/J...

Does this count as a Heisenfix?

As predicted by John Brunner's "Stand on Zanzibar" (http://en.wikipedia.org/wiki/Stand_on_Zanzibar ): a video system where your face is superimposed on the screen, showing you visiting exotic locations, participating in dramas, etc, etc?

Mod parent up +1 -Insightful- :-)

Well, I have no use for Twitter, so I guess that rules me out as a customer for the site. Unlike some others here, I actually like David Pogue's writing.

Mod parent up insightful. (My mod points ran out Monday...)

Am I the the last person in the world who uses RSS readers to browse news sites for stories that I actually want to read? After all, 90% of everything is crap and I'm looking for efficient ways to find the 10%.

The visual clutter on that site is appalling, I thought Pogue had more taste than that.

Obviously you believe you're more qualified in contract law than the lawyers who were involved. Good on you.

We bought support. But to get support from organization X, that organization has to first admit it is -their problem-. Please re-read my post to see that no organization wanted to take ownership of the problem.

"having source code wouldn't have changed anything" Disagree. Particularly at interfaces (e.g. cross-language/cross-compiler calls, APIs to COTS products, etc), sometimes you need to see inside the product to figure out what's failing at the interface. It's nice to talk about omniscient knowledge on the part of product developers, API specifiers (who might not be the same as the API implementers), and customers/users of that API for that product. Our specification techniques are by no means rigorous enough to prevent these kinds of problems.

"Risk" means just that. It's not a guarantee of failure. Rather it's the possibility of failure, coupled with (multiplied by :-) the consequences of the failure occurring.

Here's a real-world example, not related to compiler problems per-se, but relevant to your comment:

We had developed Unix RPC code that worked just fine on several systems, including the commercial product the hardware vendor was proposing. When we got to the installation for test, the code didn't work. After going up to the General Officer/SES level, and across to the vendor senior VP, I was given a copy of the vendor's source code for their RPC library. I was able to step through their code to the actual kernel syscall, and most importantly was able to see the failure value returned by the syscall. (The RPC library took that value, converted it into an ERRNO value of "EACCES", -which didn't tell us -why- the error actually happened.)

When I saw the value of the syscall, which indicated a non-privileged (not root) process was trying to do something that required 'root' privilege, I was able to go back to the vendor and ask, "Did you implement extra security features for RPC?" After some hemming and hawing, they came back and said, "Yes, you have to be root to install an RPC service." More importantly, that security feature WAS NOT DOCUMENTED. (And I can understand the rationale for saying that only privileged/root accounts can install public RPC services, so this was not an unreasonable restriction, but it was a change from standard practice in Unix systems of the time.)

This is an example of (a) a situation where the interface failed, even though all of the -code- was correct; (b) the only way I found this was to step through the vendor library to figure out the problem was -missing documentation-.

Mark parent -1 troll.

That comment just demonstrates you don't know much about these kinds of markets.

Well, in part that depends on your market. Most of my work has been in military systems or air traffic systems, where the cost of failure >> lost opportunity cost. That's a point a lot of people forget; not all markets (and therefore the risk calculations for bugs, etc) are created equal.

Unfortunately, that's not unique to GCC. I've seen this happen with several different compliers for different programming languages over the years. Worse, I've seen it with the same compiler, but different Optimizer settings.

In one case, our system didn't work (segfaulted) with the optimizer engaged, and didn't meet timing requirements without the optimizer. And the problem wasn't in our code, it was in a commercial product we bought. The compiler vendor, the commercial product vendor (and the developer of that product, not the same company as we bought it from) and our own people spent a year pointing fingers at each other. No one wanted to (a) release source code and then (b) spend the time stepping through things at the instruction level to figure out what was going on.

And the lesson I learned from this: Any commercial product for which you don't have access to source code is an integration and performance risk.

Mod parent up +1 insightful.

Unless you suspect and are trying to debug a code generator error (one of the least pleasant/most difficult debugging experiences I've had), the base assertion that you should understand your compiler's code generation is at best unrealistic, and probably just dumb. Code generation is extremely complex, requiring deep knowledge of both this specific compiler's design and this specific computer's instruction set architecture, how the caches work, pre-fetching approaches, timing dependencies in instruction pipelines, etc, etc. If you do suspect a code generator error, you're best off hiring a compiler expert at least as a consultant, and be prepared for a long hard slog.

Maybe 30 years ago, for a PDP-8, you could assert that the C code you wrote had some semblance to the generated machine code. That hasn't been true for a very long time, and C++ is most definitely not C in this regard.

in the US Military-Industrial Complex for most of the last 35 years.

If that doesn't match your ethics, that's OK.

Or 127.0.0.1 :-)