Can I make a pointer to the code, and pass to the next instruction?

Like this link http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Labels-as-Values.html

I can get the memory address of an label, so if I declare a label, get your address, and add your address, i will pass to next instruction? some ilustration >

int main () {
   void *ptr;
   label:

    instruction 1;
    instruction 2;

   ptr = &&label;

   // So if I 开发者_开发知识库do it...

   ptr = ptr + 1;
  // I will get the instruction 2 correct??

Thanks for all answers.

No, I don't think so.

First of, you seem to take the address of a label, which doesn't work. The label is interpreted by the compiler but it does not represent an actual adress in your code.

Second, every statement in C/C++ (in fact any language) can be translated to many machine language instructions, so instruction 1 could be translated to 3, 5, 10 or even more machine instructions.

Third, your pointer points to void. The C compiler does not know how to increment a void pointer. Normally when you increment a pointer, it adds the size of the data type you are pointing to to the address. So incrementing a long-pointer will add 4 bytes; incrementing a char-pointer will add 1 byte. In this case you have a void-pointer, which points to nothing, and thus cannot be incremented.

Fourth, I don't think that all instructions in x86 machine language are represented by the same number of bytes. So you cannot expect from adding something to a pointer that it gets to the next instruction. You might also end up in the middle of the next instruction.

You can't perform arithmetic on a void*, and the compiler wouldn't know what to add to the pointer to have it point to the next 'instruction' anyway - there is no 1 to 1 correspondence between C statement and the machine code emitted by the compiler. Even for CPUs which have a 'regular' instruction set where instructions are the same size (as opposed to something like the x86 where instructions have a variable number of bytes), a single C statement may result in several CPU instructions (or maybe only one - who knows?).

Expanding on an example in the GCC docs, you might be able to get by with something like the following, but it requires a label for each statement you want to target:

   void *statements[] = { &&statement1, &&statement2 };
   void** ptr;

   statement1:
    instruction 1;

   statement2:
    instruction 2;

   ptr = statements;

   // goto **ptr;      // <== this will jump to 'instruction 1'
   // goto **(ptr+1);  // <== this will jump to 'instruction 2' 

Note that the &&label syntax is described under C Extensions section in GCC docs. It's not C, it's GCC.

Plus, void* does not allow pointer arithmetic - it's a catch-all sort of type in C for pointing at anything. The assumption is that the compiler does not know size of the object it points to (but the programmer should :).

Even more, instruction sizes are widely different on different architectures - four bytes on SPARC, but variable length on x86, for example.

I.e. it doesn't work in C. You will have to use inline assembler for this sort of things.

No, because you can't increment void *.

void fcn() { printf("hello, world\n"); }

int main()
{
    void (*pt2Function)() = fcn; 

    pt2Function(); // calls fcn();

    // error C2171: '++' : illegal on operands of type 'void (__cdecl *)(void)'
    // ++pt2Function; 

    return 0;
}

This is VC++, but I suspect gcc is similar.

Edited to add

Just for fun, I tried this—it crashed:

int nGlobal = 0;
__declspec(naked) void fcn()
{ 
    // nop is 1-byte instruction that does nothing
    _asm { nop }

    ++nGlobal;

    _asm { ret }
}

int main()
{
    void (*pt2Function)() = fcn; 

    // this works, incrementing nGlobal:
    pt2Function();
    printf("nGlobal: %d", nGlobal);

    char *p = (char *) pt2Function;
    ++p; // point past the NOP?
    pt2Function = (void (*)()) p;

    // but this crashes...
    pt2Function();
    printf("nGlobal: %d", nGlobal);

    return 0;
}

It crashed because this line doesn't do what I thought it did:

void (*pt2Function)() = fcn;

I thought it would take the address of the first instruction of fcn(), and put it in pt2Function. That way my ++p would make it point to the second instruction (nop is one byte long).

It doesn't. It puts the address of a jmp instruction (found in a big jump table) into pt2Function. When you increment it by one byte, it points to a meaningless location in the jump table.

I assume this is implementation-specific.

I would say "probably not". The value of the pointer will be right, because the compiler knows, but I doubt that the + 1 will know the length of instructions.

Let us suppose there's a way to get the address of a label (that is no an extension of a specific compiler). Then the problem would really be "the next instruction" idea: it can be very hard to know which is the next instruction. It depends on the processor, and on processors like x86 to know the length of an instruction you have to decode it, not fully of course but it is anyway some complex job... on notable RISC architectures, instructions' length is a lot easier and getting the next instruction could be as easy as incrementing the address by 4. But there's no a general way to do it at runtime, while at compile time it could be easier, but to allow it in a C-coherent way, C should have the type "instruction", so that "instruction *" can be a pointer to an instruction, and incrementing such a pointer would point correctly to the next instruction, provided the code is known at compile time (so, such a pointer can't point really to everything pointer can point to in general). At compile time the compiler could implement this feature easily adding another "label" just beyond the generated instruction pointed by the "first" "label". But it would be cheating...

Moreover, let us suppose you get the address of a C label, or C function, or whatever. If you skip the first instruction, likely you won't be able to "use" that address to execute the code (less the first instruction), since without that single instruction the code may become buggy... unless you know for sure you can skip that single instruction and obtain what you want, but you can't be sure... unless you take a look at the code (which can be different from compiler to compiler), and then all the point of doing such a thing from C disappears.

So, briefly, the answer is no, you can't compute the pointer to the next instruction; and if you do someway, the fact that you're pointing to code becomes meaningless since you can't jump to that address and be sure of the final behaviour.