Thread: Microsoft V6 and V10 C++ differences in integer calculations

Originally Posted by johnggold

What a load of nonsense!

Yes. And you are sprouting it.

Originally Posted by johnggold

First, I have two Microsoft complier bugs confirmed by Microsoft. If you have ever tried this, there are a lot of hoops to jump through. So pleae don't tell me about non-existent compiler faults. Interestingly, one of the bugs was detected with the software module I am working on now.

Nobody said that compilers do not have bugs. They said that recent versions of a compiler are LESS likely to have bugs than an older version. Because, when releasing a new version of a compiler, most vendors include fixes for problems that were found in older versions.

That is not saying Microsoft did not manage to introduce a new bug .... that happens too. But the odds are in favour of the problem being in your code, not in V10 of the compiler.

Originally Posted by johnggold

Your certainty is worrying. You should read Robert Graves "Broken Images" - it's only short but it does describe your approach very well.

Second, I don't really care whether the problem is a V10 compiler bug or just an undetected feature now exposed. It is still a problem that does not occur with other versions, so it has to be V10 as the problem.

Your logic is fatally flawed. If you reported a bug, today, in the V6 compiler Microsoft's first advice would almost certainly be that you upgrade to a more recent version. Why? Because later versions of their compilers include numerous fixes of bugs that were in V6.

When code exhibits a problem with one version of a compiler, but not with another version, then the most likely source of the bug is the code itself. Yes, there is potential that you have found a compiler bug. However, on balance of probabilities, it is more likely that your problem is in your code, not the more recent version of your compiler.

You can keep searching for a compiler bug if you like. You might even isolate one. However, the smart money says that you would be better off searching for a bug in your code, and correcting that.

Thank you nvoigt for a sensible answer that I can actually use.

I can see - Grumpy - that you didn't take the trouble to read the poem. I can see that you've not pursued issues with Microsoft. It's hard work, and even when you get the admission of a bug you then get told, as I was, to wait at least a year for a fix to be issued, because you are already on the latest release. That's the real world.

You should look at nvoigts answer. He addressed the question, rather than spouting on about all the times bugs were self inflicted, assuming the compiler is not involved. Perhaps you don't mix with the right class of programmer, or maybe you are really talking about your own code quality?

Read the poem and you may begin to understand.

You're telling me it's hard pursuing issues with Microsoft... Had one issue open for ages with them that was never reproduceable in any small basic test program and was rare enough on our large code base that it never got fixed. We worked around the issue in the end. And that one was with the OS, not the compiler.

grumpy is "the right class of programmer". . You'd be hard pressed to beat his advice around here most times.

The problem here is that you always narrow the problem down in your mind to one specific little thing, and come here expecting a specific answer.
If this were a medical centre, you're doing the equivalent of walking in and demanding you be given a prescription for a certain drug because you believe you already know what's wrong with you. Even if you're right, you just can't do that.

You need to come here with an open mind, state the real symptoms, show whatever relevant code you can, be politely thankful for any and all suggestions you get no matter what you think of them, answer whatever questions you can answer, and let people actually get to the bottom of the problem for you.
Use the breadth of other people's alternate approaches to your advantage. If we all thought the way you did then we would all be just as stuck. You don't know everything, and the more time you spend here, the more you'll realise how much you don't know. That goes for all of us.

Until you change the way you interact here, you are going to meet a lot or resistance and hostility, and you are going to struggle to get any problems you have sorted out.

Originally Posted by johnggold

I can see - Grumpy - that you didn't take the trouble to read the poem. I can see that you've not pursued issues with Microsoft. It's hard work, and even when you get the admission of a bug you then get told, as I was, to wait at least a year for a fix to be issued, because you are already on the latest release. That's the real world.

Don't ever presume that you know more than other members in a forum.

You are certainly incorrect in presuming that I have never been through the cycle of submitting bug reports to Microsoft and managing workarounds in a code-base while waiting for a release that addresses the bugs.

However, one thing I have learned is that developers readily over-estimate the quality of their own code and, on that basis, jump too readily to an assumption that their problem is due to a bug in a compiler. You are exhibiting that phenomenon.

You have provided no evidence, other than the arrogance that you justify on the basis of having submitted a few bug reports to Microsoft, that your problem is due to a bug in the compiler.

Originally Posted by johnggold

You should look at nvoigts answer. He addressed the question, rather than spouting on about all the times bugs were self inflicted, assuming the compiler is not involved. Perhaps you don't mix with the right class of programmer, or maybe you are really talking about your own code quality?

nvoigt was simply making guesses - based on your unsubstantiated assertion that your problem is with the compiler - about what one contributor to your problem might be.

I consider that I mix with the right class of programmer because you are not within that class. The class of programmers I mix with are quite experienced, care deeply about the quality of their designs and code, and care enough about end-users of their code that they submit regularly to independent review and auditing. They are also honest enough with themselves to know they are human and fallible, and accept having their mistakes corrected. And they do not resort to attacks on individuals to obfuscate their mistakes, as you are doing.

I can see why you have never successfully challenged Microsoft - you can't add up according to your mantra, and as you say yourself you don't care about the times you are wrong.

I suspect 3% is on the low side, because someone who doesn't care, usually underestimates.

You certainly underestimated me, and now you've been exposed, you're a little peeved - hence the gratuitous insults - never a good substitute for facts.

I can however, back my standpoint with facts.

1. You did not pick up on the fact that I know how to debug, and that I stated right at the beginning that it is a slow process. Generating and comparing large log files always is.

2. You had no idea of my programming level, so presumed that you need to teach me how to debug - and did not answer the question.

3. You presumed that the compiler could not be the problem because you state that you don't care about the 3% of instances when you are wrong.

4. You never read the poem.

Originally Posted by johnggold

3. You presumed that the compiler could not be the problem because you state that you don't care about the 3% of instances when you are wrong.

I note that that statement is a signature; it may be merely have been chosen for laughs, with no relevance to this thread, much like how I am not asking you to "Look up a C/C++ Reference and learn How To Ask Questions The Smart Way" in this thread.

Originally Posted by johnggold

4. You never read the poem.

I just read it, and I think you should too

Frankly, the problem with this thread is that there is no (relevant) code. There is at least one bug, but whether the bug is with your code or one of the compilers used, or some combination thereof, cannot be determined (thus I am also inclined to suspect your code first, until we can rule it out). There can only be guesses that may or may not be useful.

Originally Posted by johnggold

I can see why you have never successfully challenged Microsoft - you can't add up according to your mantra, and as you say yourself you don't care about the times you are wrong.

Who is presuming now? The difference is that you are citing your experiences challenging Microsoft to somehow support your claim that your problem must be your compiler.

Originally Posted by johnggold

I suspect 3% is on the low side, because someone who doesn't care, usually underestimates.

You are referring to my signature, which is on all my posts. It is actually there as a gentle reminder that everyone should check for themselves, not accept what anyone says as gospel.

Unlike you, who expects everything you say to be treated as gospel. The word of John Gold, who has submitted bug reports and challenged Microsoft. Amen! Amen! Amen!

Originally Posted by johnggold

You certainly underestimated me, and now you've been exposed, you're a little peeved - hence the gratuitous insults - never a good substitute for facts.

You are the one who started with the gratuitous insults, not I. And you are now latching onto a signature on a forum post (not the post itself) in an attempt to cover your own exposure.

Even in the way that your complimented nvoigt appeared backhanded. Yes, I agree his post was relevant to your question, as asked. But your manner was condescending, particularly since you pointedly - by omission - chose words that suggested everyone else's post was useless, and followed up with further posts giving specific insults to those who had not followed the Gospel of John Gold.

I'll also point out that, if your code can break because the size of a struct changes between compiler versions (a particular instance of which is the substance of nvoigt's post) that it is your code at fault. Such things are inherently implementation defined, so such assumptions should not be implicitly or explicitly hard-coded.

Originally Posted by johnggold

I can however, back my standpoint with facts.

You are making assertions. You would need to provide evidence before deeming they are facts.

Oh, I forget. This is the Gospel of John Gold. Amen!

Originally Posted by johnggold

1. You did not pick up on the fact that I know how to debug, and that I stated right at the beginning that it is a slow process. Generating and comparing large log files always is.

2. You had no idea of my programming level, so presumed that you need to teach me how to debug - and did not answer the question.

I never questioned your ability to debug. I doubted your assertion that the problem was with your compiler, and not with your code. The subject line of this thread suggests you think the problem is with how the compiler handles integral operations. I provided things you need to look for in code, in order to justify your unsupported claim that the problem is the compiler.

If you submit a bug report to any vendor, and the problem is actually with your code, you will waste time. Both your own, and of the vendor. Microsoft, in this case.

Originally Posted by johnggold

3. You presumed that the compiler could not be the problem because you state that you don't care about the 3% of instances when you are wrong.

No, I did not presume the compiler was not the problem.

Based on experience I know that, when a developer claims the problem is a compiler, that most of the time the real problem is with the developer's code. I was pointing out that you need to provide evidence that the code is valid (or that you have eliminated invalid code constructs) in order to substantiate your claim that the problem is the compiler.

A previous history of submitting bug reports to a compiler vendor, and subsequently it being determined your report was actually of a bug, is insufficient to justify blind acceptance of such assertions.

Originally Posted by johnggold

4. You never read the poem.

I have read the poem, although I did not bother to make that claim. I also have never claimed that I slavishly adhere to what it says. I certainly don't when faced with someone behaving as you are.

The attitude you show is more along the lines of "do what I say, not what I do". When it suits you, you assert that others should read the poem. But, again when it suits you, you behave in a manner contrary to the message of poem. There is a word for that: hypocrisy.

I suggest you read the poem again, based on your behaviour in this thread. You might have read the poem, but your behaviour in this thread has demonstrated you failed to understand it.

I'll leave it at that, as the webmaster has asked that the debate be dropped. Enjoy your rodeo!

You might check how Modulus "%" works on negative numbers in both versions.
Negative numbers are/were undefined when working with "%" operator.

Tim S.

Originally Posted by stahta01

You might check how Modulus "%" works on negative numbers in both versions.
Negative numbers are/were undefined when working with "%" operator.

You're almost perfectly correct, Tim, but your effort is wasted. I gave that same advice earlier (point 4 in post 12 of this thread).

The gospel of John Gold is that his problem is a compiler bug, because his code is flawless. And we who may question the gospel clearly worship the devil.

> Debugging is possible, but will take quite some time, as there are millions of iterations before deviation occurs over about 19,000 lines of code.
My money is on there being at least one undefined expression in the code. And that's just two of the dozens of such traps which lie in wait, ready to create some WTF moment for the unwary traveller.

Changing compiler almost always flushes out a fresh set of bugs which were previously hidden. And almost always, it's down to some problem in the code and not the compiler.
This is nothing strange to those of us who use multiple compilers on a daily basis, but it does come as a shock to people the first time they try compiling their magnum opus on a new compiler.

How many warnings are you presently getting from your new compiler (with warnings set at maximum)?. If you've got pages of warnings to begin with, then start with a review of those warnings. If you're in the "well it compiled" camp (you just ignore them), then don't expect a lot of sympathy from us if it turns out the problem could have been solved by you paying attention to the information you already had.

Further, if you're in the business of porting nearly 20K lines of code across multiple generations of compilers, I'm guessing this is work rather than hobby.
In which case, some s/w analysis tools are definitely worth the money (how many weeks have you spent bug-chasing to no effect so far?).
The Leader in Static Analysis for C/C++ -- PC-lint and FlexeLint
Ideal if you're a solo developer or a small shop. Very good value for money, when you compare how long it would take for you to find each one manually (at $x/hour).

Software development testing| Source Code Analysis | Coverity
Favoured by industrial developers with bigger projects and bigger pockets.

But if you've never run such tools on your code before, expect a fire storm of issues to work your way through. Don't set the bar too high to start with and only fix things which would definitely be a problem. Resolve to improve the product over some sensible time line.

Hey, if you want a quick code review, post a few hundred lines (a few functions of the 20K) and we'll do a code review and tell you all sorts of interesting things about it which might trip you up when changing compilers.

The problem with work is that you prioritise, and this type of bug gets left for ages. Based on previous experience I knew that even with tools - and I have loads - it was going to take up to 2 working days. My query to this board was just to pick up any ongoing V10 issues that might be around before I started.

I've actually worked on it this weekend, and found the point of deviation. Usual problem with this type of code - all this does is show that a dependent variable got tramped on earlier and somewhere else.

Second round focused on the tramped on variable, and this showed a problem in a returned string variable from a VO library array. VO for those who don't use it is Visual Objects - which is used as the front end - to pass working data onto the C++ module.

Not the complier in this instance, but still an outside influence. In theory, this should not happen, with the procedures in place, and as I don't program in VO, it will be discussed later this week with the team.

But it does show that jumping to presumptions about quality of C++ code should not be allowed to prevent consideration of external factors - be it compliers, third party modules, or in this case another member of the team!

It goes to show that you should be open minded: "The bug could be anywhere, form my code, to external libraries, to compilers."
The chance of a bug's existence decreases as you go to the right, implying that it is usually a good idea to check your own code before anything else, especially when upgrading from such an ancient compiler that is pre-ISO C++.