Basic Runtime Check in VS C++ 2010

I’m using MSVS2010 for a previous project developed in C.

I see an issue with Debug vs. release mode. The debug mode gives me my expected result while the release mode gives me wrong result and the results produced by release mode are different in all runs (way different).

Then, I went to the project properties and turned on the Basic Runtime Check (BRC) for the Release mode. If I turn set BRC to “Stack Frames (RTCs)” or RTC1 then the result is the same as Debug mode. If I only use Uninitial开发者_C百科ized variables (RTCu), the result is wrong.

When I turn on all warnings, there are 3 types of warning in the program: 1. Replace a function X by a function X_s (to disable use _CRT_SECURE_NO_WARNINGS) 2. ‘<’: signed/unsigned mismatch. The reason is I defined

#define NO_OF_INPUTS 20
int j;
j = 0;
while (j<NO_OF_INPUTS) //The warning is for this line
{…}

4 bytes padding added after data member ‘State’. Here is the struct:

typedef struct X
{
    int State;
    double Value;
} XName;

Doing some search on google, I found this: http://msdn.microsoft.com/en-us/library/8wtf2dfz(v=vs.80).aspx

So I guess the padding stuff may be the thing… Not sure though

Any suggestion to fix the bug? And other warnings if possible…

Best.

It seems hard to give you a good hint because usually such problems occur at some point in code where the programmer makes some assumptions (conscious or not) which are not guaranteed to be fullfilled (like memory initialization etc.) by the standard. Such behaviour can also result from writing/reading to/from memory that is not "yours" (but in Debug mode the memory was initialized or you're reading/writing some bytes that are not required by the program).

It's certainly a good idea to fix warnings as you described them. However, it seems to me like this will not necessarily help. You could try cppcheck to get warnings like uninitialized memory.

If it is a memory problem, you may not get compiler warnings. In this case Microsofts (free) "Application Verifier" can sometimes help.

If it doesn't, you should write unit tests to get closer to the problem. It's a good idea anyways...