Hi guys, anyone has an idea why the same code "iOperand_0 - iOperand_1" would give a different result in linux?

1. OS Windows 7 Pro 64bit / Ubuntu Linux 18.04 64 bit.
2. IDE and compiler: Codeblocks with mingw and GCC.
3. Problem: I use the same code and compiled in on both the windows and linux version, but the result is different. On windows everything works and I get the right result. On linux I get (1--2 = -3).

1--2 = -3 in Linux.

1--2 = 3 in Windows.

 

There's a bunch of stuff here that I have no idea how to interpret it. What is this gcvt() functions. Your comment says Var2 = signs, but Var2 appears to be 10. What's that mean?

You don't initialize your iResultFlag, so if iResult is not less than zero, it is random garbage, meaning that it is probably True in line 36 since anything other than 0 is considered True.

Try initilizing it, since it is your responsibility to do so, and see what happens.

 

Update:
Sorry for the unnecessary thread, you can delete it if you want to.

The problem was that in Linux 1 variable was not cleared automatically(initialized to "0"), which lead to problems as the code remembered the output should be minus.

 

There's a bunch of stuff here that I have no idea how to interpret it. What is this gcvt() functions. Your comment says Var2 = signs, but Var2 appears to be 10. What's that mean?

You don't initialize your iResultFlag, so if iResult is not less than zero, it is random garbage, meaning that it is probably True in line 36 since anything other than 0 is considered True.

Try initilizing it, since it is your responsibility to do so, and see what happens.

In some compilers thats done automatically, but not always thats true.

 

In some compilers thats done automatically, but not always thats true.

Now you know why you shouldn't rely on a compiler doing things that are not required by the language specification -- unless you want to lock you (and whoever comes after you) to that version of that compiler on that platform.

 

Always always always initialize variables in C.

 

Always always always initialize variables in C.

Unless you want random data from a SRAM block of memory.
https://pdfs.semanticscholar.org/e823/f6078233b3f9e826f7570e794689b354f1a1.pdf

 

I understand, I had forgotten this little detail.

 

I understand, I had forgotten this little detail.

I would hate to admit the amount of time, over my lifetime, that I have spent chasing problems caused by forgotten details.

 

Unless you want random data from a SRAM block of memory.

40 years ago I worked on a system (non-Unix, non-C) which initialized new (VM) pages with 0x81 rather than 0x00. Pretty good sentinel.

20 years ago I worked with a couple of (primordial) embedded compiler packages that didn't know how to link/copy the .data initializers.

To this day I don't quite trust .bss and .data.

 

In some compilers thats done automatically, but not always thats true.

My experience has been that compiling with debug enabled will initialize all variables, but otherwise, it's programmer responsibility.

 

My experience has been that compiling with debug enabled will initialize all variables, but otherwise, it's programmer responsibility.

That's been hit and miss for me. I hate debuggers that intentionally make the code behave different than the release version -- seems rather stupid to me. The same with logic simulators that always initialize flip-flops to LO. Since I grew up in the age of little to no debugger availability, I got used to debugging my code through a combination of incremental development and instrumenting it with console output, so that's what I naturally fall back on. Don't take that to mean that a good debugger, and the ability to use it well, isn't worth it.

 

My experience has been that compiling with debug enabled will initialize all variables, but otherwise, it's programmer responsibility.

I'll second that, and you can make things really entertaining by building the code for debug with optimization turned on as well. Specifically I used gcc and gdb extensively, not quite as much Visual Studio. After enough frustrating experiences with stepping through your code line by line to assure yourself it works, only to have the production code fail on the target device, you just get in the habit of taking nothing for granted.

 

Debugging optimized code is definitely an experience, I'll leave it at that. I think we've all used console prints to debug at some point, and sometimes the delay caused by the line printing actually creates or hides problems. Such as when debugging problems caused by race conditions. It has been a while, but I believe you can set default memory values in Visual Studio, and probably gcc. Side note; I've also found the memory break points in Visual Studio to be unreliable. When a byte in memory mysteriously changes, so you set a break point on that byte, the break point never trips yet your memory is still changing. But for the most part I find Visual Studio to be a really excellent debugger. The remote debugging features are also fantastic (debugging code that is running on a remote machine), you can even debug kernel level stuff over a network now.