A: 

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.

0x6adb015
+5  A: 

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.

Patrick
@Patrick: as far as the first point - this is permitted as an extension in GCC.
Michael Burr
Didn't know that Michael (I'm using solely Visual Studio). Thanks for the information. In which situations is it useful to take the 'address' of a label?
Patrick
@Patrick: I'm not sure there are a lot of useful situations - as far as I know it's mainly to support a 'computed goto' - see the doc link in the question. Most of those situations would be better off with a switch statement (or a more considerable refactoring). I think another (still unlikely to be necessary and very non-portable) use might be for low-level stuff (dump opcodes or whatever).
Michael Burr
@Patrick: I think that gcc may also allow you to add two void pointers (with the semantics `ptr = (void *)(((int)ptr)+1);`, same as `char*`), but it's not standard. Also, you might want to add that it is entirely possible for there to be some target processor to execute instructions from high addresses to lower addresses. I don't think that one exists, but nothing prohibits it.
nategoose
+1  A: 

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.

Nikolai N Fetissov
GC-C? Garbage collected C?
kmm
Goblin-Created-Compiler
Nikolai N Fetissov
+1  A: 
egrunin
Oownn, very nice example! I will think some about this code, and find a way to make it work! thanks so much!
drigoSkalWalker
A: 

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' 
Michael Burr
A: 

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.

ShinTakezou