Re: C++, XS, and dNOOP, or Doing Nothing is Hard Work

On Sat, May 5, 2012 at 6:25 PM, Craig A. Berry <[email protected]> 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