#include <windows.h>
int WINAPI WinMain(HINSTANCE hI, HINSTANCE hPI, LPSTR acCmdLine, int iWinMode)
{
char acXYZPath[260];
strcpy_s(acXYZPath, 260, &acCmdLine[1]);
return 0;
}
VC80 Optimize for maximum speed bug
Author
It's just not debugging right due to the optimizations. Go ahead and put a message box there to display your string, it should come out fine.
And depending on how smart the optimizer is, it might have removed the entire strcpy_s call, since it might have recognized that you never use the result and the CRT function call has no side effects.
As MJP said, put in a message box and everything will work as expected. Debugging release code is a lot harder than debugging debug code, and should not be attempted by a beginner.
As MJP said, put in a message box and everything will work as expected. Debugging release code is a lot harder than debugging debug code, and should not be attempted by a beginner.
Why does the debugger have so much trouble in release mode? All strings are always offset and such, what real differences does it do to the code?
> Why does the debugger have so much trouble in release mode?
> All strings are always offset and such, what real differences does it do to the code?
What Yann L is getting at is that your code doesn't actually do anything, so therefore there is no reason to generate any code, or even create any of your strings.
> All strings are always offset and such, what real differences does it do to the code?
What Yann L is getting at is that your code doesn't actually do anything, so therefore there is no reason to generate any code, or even create any of your strings.
An easy way to check if the compiler actually produced the code for the call is to turn on assembly output. That is of course if you can read assembler code. But it's pretty unlikely that the compiler calls strcpy_s in this situtation because - as it has been mentioned - it has no side effects.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
