Comment Re:Very different code (Score 1) 225
Obviously you believe you're more qualified in contract law than the lawyers who were involved. Good on you.
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
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
That throws them off-script. I say, "If you're telling me my computer has viruses, you must know the IP address of the infected computer."
And then when they give me some Windows mumbo-jumbo, I'll say, "But all the computers here are Macs."
Not sure why this was rated 'Troll'. I could see it as 'irrelevant to the topic', but what I reported here is what I saw on LH 414, 16 NOV 2013.
The entertainment system on the LH A340-300 I flew yesterday wasn't booting. We could see the Windows CE console boot sequence where it would hang. The pilot came on the loudspeaker and told us he had to power-cycle the entire aircraft. (I'm pretty sure he meant just the cabin power.) Several people said, "Makes sense if it's running Windows," and another asked, "They aren't using Windows in the cockpit, are they?"
(Once it did boot up, touch panel performance was poor, and video playback had a fair amount of stutter.)
Do you really think a French MEP's re-election will be impacted by a terrorist strike in the UK, or vice versa?
Well, there have been indications to that effect. But my response is not -predicated- on the prior existence of such agreements.
Rather it asserts the willingness of the US to share -in the future- would be impacted by an European unwillingness to share.
Well, until there's an Edward Snowden equivalent from UK, France, Germany, etc; I'm not sure I believe there are no reciprocal data sharing agreements.
"No matter where you go, there you are..." -- Buckaroo Banzai