problems with C9x's _Pragma

[Zack Weinberg <zack at rabi dot columbia dot edu>]

C9x has an alternate form of #pragma:

_Pragma ( "string of tokens" )

is interpreted as if

#pragma string of tokens

had appeared in the same place in the source file.  This would be fine
except that there are no constraints on where #pragma, hence
_Pragma(), is allowed to appear.  Theoretically, this code is legal:

int bar(void);

int foo(void)
{
  return _Pragma("something") bar();
}

Also, _Pragma must be recognized
even if I do something like this:

#define LP (
#define RP )

_Pragma LP "string" RP

*That* would be fine as long as _Pragma was interpreted only by cc1.
Some pragmas, however, affect the preprocessor: once, implementation,
the proposed charset.  The preprocessor is not capable of handling
this.  Making it do so would be prohibitively difficult.

I'd like to propose we place two constraints on #pragma and
_Pragma():

_Pragma() must appear as a separate statement, with a semicolon
after it.  It can appear where statements or declarations are legal.
#pragma must appear where it would have been legal if it were written
the other way, in addition to being valid as a preprocessing
directive.

Pragmas that affect the preprocessor cannot be written using
_Pragma().

No supported or proposed pragmas are broken by these constraints.  No
s.c. C9x program can tell the difference, since the only standard
pragmas are ones that affect cc1.

zw