Grepping the CORE directory I get in all 3 perls

lib\CORE/op.h:#define GIMME_V                OP_GIMME(PL_op, block_gim
+me())
[download]

What matters is not no much that the macro #define doesn't differ, but what machine code the compiler has generated for it.  After full macro expansion, the GIMME_V macro looks like:

((((*Perl_Top_ptr(((PerlInterpreter *)pthread_getspecific((*Perl_Gthr_
+key_ptr(((void *)0))))))))->op_flags & 3) == 1 ? 128 : (((*Perl_Top_p
+tr(((PerlInterpreter *)pthread_getspecific((*Perl_Gthr_key_ptr(((void
+ *)0))))))))->op_flags & 3) == 2 ? 0 : (((*Perl_Top_ptr(((PerlInterpr
+eter *)pthread_getspecific((*Perl_Gthr_key_ptr(((void *)0))))))))->op
+_flags & 3) == 3 ? 1 : Perl_block_gimme(((PerlInterpreter *)pthread_g
+etspecific((*Perl_Gthr_key_ptr(((void *)0))))))))
[download]

(this is for a threaded 5.8.8 — replace cc -c ... with cc -E ... in the compiler call issued by Inline::C to obtain the respective snippet for whatever Perl version you're interested in)

As you can see, some Perl-internal functions/structures are being accessed. And problems may arise if the machine code for this macro generated by the compiler used to compile the extension DLL does not address memory as layed out by the compiler(+options) that compiled the perl DLL (for example, op_flags might be aligned differently (just for the sake of argument — not saying this is necessarily the issue in this particular case)).

I get your point regarding memory layout.

The macro does expand the same for me

perl 5.10.1

void foo() {
    printf("%x\n", ((((*Perl_Iop_ptr(((PerlInterpreter *)Perl_get_cont
+ext()))))->op_flags & 3) == 1 ? 128 : (((*Perl_Iop_ptr(((PerlInterpre
+ter *)Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((*Perl_Iop_p
+tr(((PerlInterpreter *)Perl_get_context()))))->op_flags & 3) == 3 ? 1
+ : Perl_block_gimme(((PerlInterpreter *)Perl_get_context()))));
    printf("%x\n", 1);
    printf("%d\n", ((((*Perl_Iop_ptr(((PerlInterpreter *)Perl_get_cont
+ext()))))->op_flags & 3) == 1 ? 128 : (((*Perl_Iop_ptr(((PerlInterpre
+ter *)Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((*Perl_Iop_p
+tr(((PerlInterpreter *)Perl_get_context()))))->op_flags & 3) == 3 ? 1
+ : Perl_block_gimme(((PerlInterpreter *)Perl_get_context()))) == 1);
}


strawbery 5.10.0

void foo() {
    printf("%x\n", ((((*Perl_Iop_ptr(((PerlInterpreter *)Perl_get_cont
+ext()))))->op_flags & 3) == 1 ? 128 : (((*Perl_Iop_ptr(((PerlInterpre
+ter *)Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((*Perl_Iop_p
+tr(((PerlInterpreter *)Perl_get_context()))))->op_flags & 3) == 3 ? 1
+ : Perl_block_gimme(((PerlInterpreter *)Perl_get_context()))));
    printf("%x\n", 1);
    printf("%d\n", ((((*Perl_Iop_ptr(((PerlInterpreter *)Perl_get_cont
+ext()))))->op_flags & 3) == 1 ? 128 : (((*Perl_Iop_ptr(((PerlInterpre
+ter *)Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((*Perl_Iop_p
+tr(((PerlInterpreter *)Perl_get_context()))))->op_flags & 3) == 3 ? 1
+ : Perl_block_gimme(((PerlInterpreter *)Perl_get_context()))) == 1);
}


activeperl  v5.8.9  build 825 [288577]

void foo() {
    printf("%x\n", ((((*Perl_Top_ptr(((PerlInterpreter *)Perl_get_cont
+ext()))))->op_flags & 3) == 1 ? 128 : (((*Perl_Top_ptr(((PerlInterpre
+ter *)Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((*Perl_Top_p
+tr(((PerlInterpreter *)Perl_get_context()))))->op_flags & 3) == 3 ? 1
+ : Perl_block_gimme(((PerlInterpreter *)Perl_get_context()))));
    printf("%x\n", 1);
    printf("%d\n", ((((*Perl_Top_ptr(((PerlInterpreter *)Perl_get_cont
+ext()))))->op_flags & 3) == 1 ? 128 : (((*Perl_Top_ptr(((PerlInterpre
+ter *)Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((*Perl_Top_p
+tr(((PerlInterpreter *)Perl_get_context()))))->op_flags & 3) == 3 ? 1
+ : Perl_block_gimme(((PerlInterpreter *)Perl_get_context()))) == 1);
}
[download]

problems may arise if the machine code for this macro generated by the compiler used to compile the extension DLL does not address memory as layed out by the compiler(+options) that compiled the perl DLL (for example, op_flags might be aligned differently

Isn't this the sort of thing that would most likely cause a crash, rather than a wrong value being returned ?
And it would seem to be a coincidence that such a misalignment actually returns one of the three *meaningful* values (0, 1, 128) instead of a nonsense value.

I guess anything is possible - and the proof probably lies in the debugger (as you've already mentioned).

Cheers,
Rob