[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: problems with C9x's _Pragma
From:       Paul Eggert <eggert () twinsun ! com>
Date:       1998-12-31 23:11:46
[Download RAW message or body]

   From: Zack Weinberg (zack@rabi.columbia.edu)
   Date: Mon, 21 Dec 1998 23:43:24 -0500 

   Theoretically, this code is legal:

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

Yes, and there's no problem with that example, as it is equivalent to
the following:

int bar(void);
int foo(void)
{
  return
# pragma something
  bar();
}

which GCC already allows.

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

   #define LP (
   #define RP )

   _Pragma LP "string" RP

The way I read draft C9x, this is not required.  Admittedly the draft is
muddy in this area.  This topic has already come up in comp.std.c and
my impression is that the committee will fix any ambiguity in the draft.


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

   [1] _Pragma() must appear as a separate statement, with a semicolon
   after it.

This doesn't match draft C9x, which says that e.g.
`_Pragma ("STDC FP_CONTRACT DEFAULT")' must work without a semicolon.
I don't see why the semicolon is needed.

   It can appear where statements or declarations are legal.

If we're talking about the STDC pragmas, this is more generous than
what draft C9x requires.  Draft C9x requires that a STDC pragma appear
either outside external declarations, or at the start of a compound
statement.  So you would allow

if (x == 0) _Pragma ("STDC FP_CONTRACT DEFAULT");

whereas draft C9x would not.  I'm not sure that it's wise to relax the
draft C9x restrictions for the STDC pragmas, as the above code (which has no
effect, since the scope of the pragma is just the then-part of the if)
probably doesn't mean what the user intended.

Conversely, if we're talking about non-STDC pragmas, I don't see why
the restriction is needed.  Other compilers do not have this
restriction for similar constructs; e.g. I've heard that

float __pragma (__mycall) FloatAdd (float n1, float n2);

is allowed by Watcom C, and similar _Pragma expressions might be
useful for GCC.  To some extent, my impression is that _Pragma is the
draft C9x way of doing GCC's __attribute__; it might be useful at some point
to put in a pragma that has the equivalent effect to __attribute__.

   #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.

This sounds backwards; by definition, _Pragma is translated to
#pragma, not the other way around.  Wherever #pragma is valid, the
corresponding _Pragma must be valid.


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

This is a reasonable restriction for some pragmas (e.g. one that
affects the character set) but I don't see why it's reasonable for
others (e.g. `#pragma implementation').  Also, any such restriction
should be phrased in terms of #pragma, not _Pragma, since the draft
C9x specifies the latter in terms of the former.

   No supported or proposed pragmas are broken by these constraints.

Hmm, not even `#pragma implementation'?

[prev in list] [next in list] [prev in thread] [next in thread]