On Sat, May 5, 2012 at 6:25 PM, Craig A. Berry <craigbe...@mac.com> wrote: > Thanks for the suggestion. That might work, but might also fall afoul of the > naked semicolon problem noted in the comment in perl.h: > > #define NOOP /*EMPTY*/(void)0 > /* cea2e8a9dd23747f accidentally lost the comment originally from the first > check in of thread.h, explaining why we need dNOOP at all: */ > /* Rats: if dTHR is just blank then the subsequent ";" throws an error */ > /* Declaring a *function*, instead of a variable, ensures that we don't rely > on being able to suppress "unused" warnings. */ > #define dNOOP extern int Perl___notused(void) > > But maybe that error would only happen with C and not C++?
That's what he just said, it's only a problem when mixed statements and declarations are not allowed. They are allowed in C99 and C++, but not in C89. > The definition of dNOOP is an extremely well-trodden line of code with lots > of changes demonstrating that anything that fixes a problem with it is highly > likely to introduce one or more other problems. > > I don't actually understand why we need a dNOOP that's distinct from NOOP, > i.e., why we can't just do: because: dNOOP; int foo; Should work on a strict C89 compiler. That means that on such a compiler, dNOOP must translate to a declaration. On a more lenient compiler it doesn't matter what it compiles to (as long as it is a no-op, obviously). Leon
