#define goto _asm JMP

Softice was nice enough to give me some assembler for something which I was converting to C. In the first stages of doing so, I turned JMP instructions into gotos.

Now, VC++6 had a problem. For some odd reason, the gotos weren't going to the right place! Clearly in the code the labels were placed correctly and the gotos were asking for those places, but stepping through in the debugger went to completely the wrong spot.

the work around:
#define goto _asm JMP
placed above the functions completely changed things. I redefined goto to do exactly what I've always thought goto did in the first place. Now the function worked.

Can anyone explain the phenomenon?

Well first of all you don't need to convert the asm to use gotos. MSVC allows the use of local labels albeit it is a bit strange looking.

Code:

---

COMPARE:
  asm {
    mov  eax,[value]
    cmp  eax,[value2]
    jz      EQUAL
    jmp    NOTEQUAL
  }
EQUAL:
  asm {
      ...do something
  jmp DONE
  }
NOTEQUAL:
  asm {
    ..do something
  }
DONE:
...can start coding in c again

---

So defining goto as a jmp instruction is not necessary. It is possible there is more to a goto than a simple jmp, but I doubt it. I'm not sure why you are having the trouble you are - but coding the asm in the above manner should clear it all up.

Not wise to redefine reserved words using #define.

I am actually using the labels now. That's what I'm jumping to. the goal is to port to C. Dis-assemble. At this point there is no assembler code left :)

additionally. In the end I have no intention of leaving gotos in the code. It is to be restructured to use the same algorithm but in C.

The question is really for understanding of the compilers limitations. I wondered if perhaps VC++ can only handle so many gotos in a function, etc.

I'm not sure if it can only handle so many gotos or not. I would not think there would be a limitation since if goto's do indeed translate to jmps - there are a million of 'em anyways in the actual assembler produced by the compiler.

If you are porting this to pure C, you should be able to re-structure the code to eliminate the gotos, as you have said. Beyond that I'm really not sure what is going on.

Kinda lost on this one.

I was attempting to do the restructuring gradually to test the thing along the way to make sure its still working. But the goto thing freaked me out a little bit. I thought someone else might have run into the same thing. It's interesting though.