Removing bugs from bug free functions

[Dann Corbit]

Do you have a public repository?

[Cardoso]

Do you have a public repository?

Thanks Dann for the helping spirit, I dont have a public repository because I'm competing against two other programs, Triturator from Spain and Aurora Borealis from Russia.
It's OK, I've been making a match against Aurora Borealis from Russia, I think we have played more than 70 games from a total of 98 games at 30 minutes plus 20 seconds, and my engine has won I think more than 10 games with zero losses, I think 2 wins were from testing games with critical openings. My friend Herson from Costa Rica keeps all the records from the ongoing match not yet published.
http://damasclasicas.blogspot.com/
My engine didn't crash a single time during the match and never made a blunder so I guess we can't rule out the possibility of MVC compiler having bugs.

[noobpwnftw]

Raise stack reserve size. Inlining this function causes stack overflow.

[Ras]

But with optimizations disabled and the nonsense code disabled the engine doesn't crash and no errors are reported.

Yes, that's typical for undefined behaviour. With optimisations enabled, the compiler is just more likely to make assumptions that no undefined behaviour exists and omit code parts or situations that would imply undefined behaviour. That can be e.g. signed integer wrap-around, or some shift operation that is at least as wide as the data type. Like, shifting a 64 bit integer by 64 bit or more. Adding or omitting any code may prevent such an optimisation in a specific case by sheer accident.

You could try raising the warning level, see https://docs.microsoft.com/en-us/cpp/bu ... ew=vs-2019 , and using the free static code checker CppCheck, see http://cppcheck.sourceforge.net/ .

[Dann Corbit]

I highly recommend CLANG not for compiling, which is just on par with gcc, but as a free Lint, because the error checking is so good.

[mvanthoor]

So I guess I'm going back to the faster way of fixing this with the code:

Code: Select all

if (4 == 5) PrintGeneralText(" 4 == 5 ");

This is strange. "if (4 == 5) doSomething()" is the same as "if (false) doSomething()". You have an unreachable branch.

In Rust, the compiler will warn you about that, and proceed to strip it from the code. Having it in there or not would make no difference to the final program. I would expect that a C or C++ compiler does the same. In case of CLANG, it probably will, because CLANG and rustc both compile down to LLVM intermittent code, where the LLVM backend takes over for optimization. I don't know about GCC-compilers or MSVC.

[mar]

if you can use VS2019 and do a 32-bit build, you can try to enable ASAN (finally) to see if it detects any problems. 64-bit ASAN will come in the next version I think.
One can never rule out compiler bugs, but these are rare. Also don't forget that in debug mode everything is pre/post-filled with specific patterns (I'm talking Microsoft compiler here), like uninitialized memory has a specific filler, freed memory another and so on => this might explain the difference between debug and release build.

[Sesse]

Or you can use Clang, which has 64-bit ASan (also on Windows).

[Cardoso]

Thank you all for your help, as soon as I get some free time I'll try again.
best regards,
Alvaro

[MOBMAT]

That isn't a bug-free function most likely. Typically when you can add code and hide the bug, look for uninitialized data that moves around on the stack depending on what extra code you insert...

In your case, function parameters can be wrong as well. IE you reference arrays using subscripts that might be invalid. I'd start by inserting code (or asserts) to verify that every argument is valid every time you call the thing.

I agree with Bob. Put in assert() in every method to test the passed parameters. Square numbers, color, etc. assert()s will automatically commented out when you build for performance. assert() has saved my "ass" so many times! LOL