This is the mail archive of the
mailing list for the GCC project.
Re: Question about #pragma removal
- From: mike stump <mrs at windriver dot com>
- To: brett dot cook at intel dot com, gcc at gcc dot gnu dot org
- Date: Thu, 14 Mar 2002 14:20:02 -0800 (PST)
- Subject: Re: Question about #pragma removal
> From: "Cook, Brett" <firstname.lastname@example.org>
> To: "'email@example.com'" <firstname.lastname@example.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
[#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
[#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
> 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
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.