This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about #pragma removal


> From: "Cook, Brett" <brett.cook@intel.com>
> To: "'gcc@gcc.gnu.org'" <gcc@gcc.gnu.org>
> Date: Thu, 14 Mar 2002 08:49:11 -0800

> 	It is impossible to generate #pragma commands from a macro. 

This point is no longer true:

       6.8.9  Pragma operator

       Semantics

       [#1] A unary operator expression of the form:

               _Pragma ( string-literal  )

       is processed as follows.  The string-literal is destringized
       by  deleting  the L prefix, if present, deleting the leading
       and trailing double-quotes, replacing each  escape  sequence
       \"  by a double-quote, and replacing each escape sequence \\
       by a single backslash. The resulting sequence of  characters
       is   processed   through  translation  phase  3  to  produce
       preprocessing tokens that are executed as if they  were  the
       pp-tokens   in   a  pragma  directive.   The  original  four
       preprocessing tokens in the unary  operator  expression  are
       removed.

       Examples

       [#2] A directive of the form:

               #pragma list on "..\listing.dir"

       can also be expressed as:

               _Pragma ( "listing on \"..\\listing.dir\"" )

The manual is behind the times.

> These two reasons apply to almost any application that might be
> proposed for #pragma. It is basically a mistake to use #pragma for
> anything.

> What I don't understand is how __attribute__ eliminates this
> problem.  I cite the following examples:

> 1)  There is no telling what the same __attribute__ might mean to another
> compiler

Yes, there is, survey them.  The probability is in fact zero that they
have a meaning that differs from gcc.  And it is reasonably likely
that it will remain that way for a long time.

Now, survey #pragma.  The risk/danger is much higher.  Though, all in
all, the reasoning in the manual is kinda weak.  Part of the solution
is namespace control, say, by using $pragma GCC ....  By doing this,
we can drop the risk of clashes down into the noise.

> 2)  For compiler specific features, such as the #pragma, or the
> __attribute__ feature, it is a mistake to not surround these lines with
> preprocessor statements such as '#ifdef GNU_C' or '#ifdef MSC'.

Not really.  The code is non-portable to start with.  Putting #ifdef
GNU_C only obscures that fact more.  Littering code with #if GNU_C/MSC
is a mistake.

> Anyway, I'd be interested in hearing an explanation (other than the
> two lines in the documentation) as to why #pragma is unacceptable.

My take on it is that pragma isn't really unacceptable, it is just
what happens to be in the manual currently.  Some ports have various
pragmas they support.  Some ports don't support any pragmas.  All
ports support attribute.  This is more just an observation of what is.
At some point in time, I suspect someone will contribute work to
smuggle the full power of attributes into pragmas.  And then, at some
point, all of our examples will change to use that form, and then at
some point attribute may go away.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]