incorrect argc in win32 (in addition, the arguments are ignored)

Question

I was coding in win32, and my program actually works in debug mode in vs, however not in release mode and not outside vs.

int _tmain(int argc, _TCHAR* argv[])
{
    //assert that there are 3 parameters.
    assert(argc==4);
    LPCTSTR inputPath = argv[1];
    LPCTSTR sharedName = argv[2];
    LPCTSTR logPath = argv[3];

sometimes argc is not correct (over 300000, while it should be 4), and sometimes the

LPCTSTR sharedName = argv[2];

line is just ignored! when debugging this program in release mode, it jumps over it, and when hoovering above the variable name nothing happens. When right-clicking a variable and choosing Add Watch, I get the error logPath CXX0017: Error: symbol "logPath" not found
of course, I have set the command arguments in vs to be "a b c" (without the quotes)

What could it be? running the simplified program: // test.cpp : Defines the entry point for the console application. //

#include "stdafx.h"
#include "stdafx.h"
#include <windows.h>
#include <assert.h>
#include "conio.h"

int _tmain(int argc, _TCHAR* argv[])
{
    assert(argc==4);
    LPCTSTR inputPath = argv[1];
    LPCTSTR sharedName = argv[2];
    LPCTSTR logPath = argv[3];
    _getch();
}

yields the same result. the debugger just jumps to the getch line, and if I try to add watch, I get logPath CXX0017: Error: symbol "logPath" not found
inputPath CXX0017: Error: symbol "inputPath" not found
sharedName CXX0017: Error: symbol "sharedName" not found

because in debug mode it works, and outside vs it doesn't, I I can't figure out why. — user1114365, May 11 '12 at 19:21
Can you provide more detail on exactly how you observe that the program behaves differently between Debug mode and outside VS? — Brian Nixon, May 11 '12 at 19:27
`assert(argc == 4)` is a totally inappropriate failure mode. `assert` should be used for logical errors, not for runtime ones. — jamesdlin, May 11 '12 at 23:27
I find it hard to believe that `argc` is wrong. Try printing out its value or change the `assert` to an `if` check that isn't compiled out in release builds. — jamesdlin, May 12 '12 at 05:43

Cody Gray - on strike · Answer 1 · 2012-05-11T19:35:27.407

when debugging this program in release mode, it jumps over it, and when hoovering above the variable name nothing happens. When right-clicking a variable and choosing Add Watch, I get the error logPath CXX0017: Error: symbol "logPath" not found

These symptoms make sense. "Release" mode tells the compiler to turn optimizations on, and since you never use the variables that you declare, the compiler helpfully optimizes them out altogether. There's no point in going through the motions of creating and assigning something if you'll never use it again.

That's why it's telling you that the symbol is not found, because its definition was optimized out.

On the other hand, "Debug" mode it disables optimizations. Thus, it goes through the motions of creating these variables and assigning values to them, even though you may never use them. That's the whole point of debug mode—so you can debug your application without interference from the optimizing behavior of the compiler, even when it's not completely written yet.

If you're desperate to make it work like you expect with optimizations enabled (i.e., in "Release" mode), then you can simply use the values of the variables you assign. That will prevent the compiler from optimizing them out. For example, you can simply output the strings to the debugger:

#include "stdafx.h"
#include <windows.h>
#include <assert.h>
#include <conio.h>

int _tmain(int argc, _TCHAR* argv[])
{
   assert(argc==4);
   LPCTSTR inputPath  = argv[1];
   LPCTSTR sharedName = argv[2];
   LPCTSTR logPath    = argv[3];

   OutputDebugString(inputPath);
   OutputDebugString(sharedName);
   OutputDebugString(logPath);

   _getch();
}

In the "real" program they are used. It works in debug mode in VS but not outside. The variables are of course used... — user1114365, May 12 '12 at 04:24
@user This is why most people post the actual code they're using in their question. — Cody Gray - on strike, May 12 '12 at 04:26
Now if I run the program in vs in debug mode it doesn't work, however if I debug it in debug mode (step-into) it does work! How can I debug it then? — user1114365, May 12 '12 at 05:49

incorrect argc in win32 (in addition, the arguments are ignored)

1 Answers1