masm32 assembly errors only while in debug mode

[PBrennick]

Jimg,
I guess you could call it a soft error.  And the workaround is as we have just said, move the data.  When I moved the data, the error went away as Greg theorized it would.  Did you miss that part of my post?  :wink

Paul

[Jimg]

The problem is that the data is dynamically created by the print macro based upon what the for loop extracts from the input string.  Theoretically, I could figure out what each should be, every time I make a change to the input string, allocate a data string, and figure out some way to get the address of that string based upon what the for loop extracts later on, but that's the whole purpose of loops and macros and all that good masm stuff, so I don't have to do the overhead myself :bg

[MichaelW]

Does the release version actually execute correctly, or does it just assemble without error?

[Jimg]

The release version seems to work perfectly here.  I have, of course, now moved on to a different way of doing the code.  But it's still a curiosity why the debug version should be having problems. 

[hutch--]

Jim,

I personally find a debugger about as useful as a hip pocket in a singlet and protected mode Windows does not help much either. For REAL MEN with a lot of money and time to waste, SOFTICE and it current successor is the boss of the block but its primarily used for driver development.

What I personally do with macro code is either expand it and look at the /EP output or disassemble it and look at the opcode generation, both of which are precision ways to test out macro code.

The last debugger I liked was 1990 Microsoft Codeview that came with MASM as I used to write code back then that looked like a debugger listing but those days are long gone and the later ones are poor in comparison and the code is far more complex in a multitasking environment.