Step debugging works fine but debugging without stepping causes strange error when using _tprintf

Question

Ok, i am going to keep this simple and not include all the code (yet) if I don't need to. My inner senses tell me that there is probably a simple answer to this and I have overlooked it as usual. More inexperienced might say the compiler is the problem but I have never known that to be the case 99.999% of the time it has always been an error on my part in some way so... heres the question. I have a program, this program is supposed to output two strings, nothing fancy

TCHAR* firststring = _T("FirstValue");
TCHAR* secondstring = _T("SecondValue");

_tprintf(_T("%s\n"),firststring);
_tprintf(_T("%s\n"),secondstring);

which outputs..

firststring

in the particular section of my code, this does not work (it works elsewhere) UNLESS i am step-over-debugging... then it is fine...

firststring
secondstring

I have even tried combining the operation into one by doing this:

_tprintf(_T("%s\n[%s]\n"),firststring,secondstring);

My result is, the first string, and the braces are there to try to point out that the string is trying to be print out and if it is empty, etc. I get this output:

firststring
]

and that's it.. again, UNLESS step-over debugging, then its all fine and dandy:

firststring
[secondstring]

has anyone ever heard of a problem like this? The last time I encountered weird problems like this was back in the ASM days with segment alignment but I doubt that is the case here, although I am not sure on _tprintf's inner workings... I'm going to try this again, if nobody knows, i'll assume its because of a error caused by the code earlier. The main question is, does this happen for any simple reason or does this just point to problems earlier in the program, that's all. Thanks for your reply.

PS: I realize that I didn't supply sufficient code to completely answer the problem, but the question is whether or not there is a known simple cause to this kind of behavior in the debugger (run vs. step-over). The breakpoint is set at the function level, I'm using Visual Studio 2008. Compiler Versions follow:

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 80x86
Microsoft (R) Macro Assembler Version 9.00.21022.08
Microsoft (R) Incremental Linker Version 9.00.21022.08
Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0
Microsoft Browse Information Maintenance Utility Version 9.00.21022
Microsoft (R) Manifest Tool version 5.2.3790.2075

Answer 1

I later resolved this issue by changing these strings from TCHAR* to const TCHAR* when using read only strings it's supposedly undefined behavior to write a string array with a string literal. I'm not sure if it was because the document itself was being stored as unicode or if that even had a part to play but I learned the hard way not to assign like that. And had I needed to write to those locations I should have used a separate constant string and copied it's contents with strcpy when i needed it in a read/write buffer. Apparently not doing that would cause security holes and other pitfalls to appear in the code even though it was simple.

(below is my reasoning on only partial code -- mouse over if interested)

As for the code sample not being complete, it was a very large project with thousands upon thousands of lines of code and I pretty much did not expect anyone on here to take THAT much time to go through it all. After all, its not like anyone here is paid to do so, and i really just needed to find out whether it was me or if this was a common thing and if it was a common thing, how to fix it. When we ask questions here, we aren't only asking a question, but we are also giving guidelines on how wide of a scope we expect the answer to be, and in no way do we ever expect anyone to be clarvoyant as some seem to suggest. If you don't want to answer a question or there isn't enough information for you to do so, then just don't its that simple (it's because we don't have all the information that we ask in the first place).