Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Clarification on _Pragma "operator"
20 views
Skip to first unread message
Keith Thompson
May 15, 2012, 12:16:14 AM5/15/12
to
N1570 6.10.9p1 says:
A unary operator expression of the form:
_Pragma ( string-literal )
is processed as follows:
[explanation deleted]
This was added in C99. The C99 Rationale says:
As an alternative syntax for a #pragma directive, the _Pragma
operator has the advantage that it can be used in a macro
replacement list.
Is _Pragma really a unary operator? If so, does that imply that it can
only be used in a context that allows a unary expression? That doesn't
seem to be the intent; rather, it seems that _Pragma should be valid
anywhere an equivalent #pragma is valid.
Another oddity is that this section is the only one in the standard that
uses the phrase "unary operator expression"; other sections refer to
"unary expression".
Wouldn't it be clearer and more consistent to refer to
_Pragma ( string-literal )
as just a sequence of preprocessing tokens, rather than pretending it's
an expression?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
A unary operator expression of the form:
_Pragma ( string-literal )
is processed as follows:
[explanation deleted]
This was added in C99. The C99 Rationale says:
As an alternative syntax for a #pragma directive, the _Pragma
operator has the advantage that it can be used in a macro
replacement list.
Is _Pragma really a unary operator? If so, does that imply that it can
only be used in a context that allows a unary expression? That doesn't
seem to be the intent; rather, it seems that _Pragma should be valid
anywhere an equivalent #pragma is valid.
Another oddity is that this section is the only one in the standard that
uses the phrase "unary operator expression"; other sections refer to
"unary expression".
Wouldn't it be clearer and more consistent to refer to
_Pragma ( string-literal )
as just a sequence of preprocessing tokens, rather than pretending it's
an expression?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jens Gustedt
May 15, 2012, 4:43:19 PM5/15/12
to
Am 15.05.2012 06:16, schrieb Keith Thompson:
> N1570 6.10.9p1 says:
>
> A unary operator expression of the form:
> _Pragma ( string-literal )
> is processed as follows:
>
> [explanation deleted]
>
> This was added in C99. The C99 Rationale says:
>
> As an alternative syntax for a #pragma directive, the _Pragma
> operator has the advantage that it can be used in a macro
> replacement list.
>
> Is _Pragma really a unary operator? If so, does that imply that it can
> only be used in a context that allows a unary expression? That doesn't
> seem to be the intent; rather, it seems that _Pragma should be valid
> anywhere an equivalent #pragma is valid.
>
> Another oddity is that this section is the only one in the standard that
> uses the phrase "unary operator expression"; other sections refer to
> "unary expression".
I found one other reference for the term in 6.10.1 for "defined"
> N1570 6.10.9p1 says:
>
> A unary operator expression of the form:
> _Pragma ( string-literal )
> is processed as follows:
>
> [explanation deleted]
>
> This was added in C99. The C99 Rationale says:
>
> As an alternative syntax for a #pragma directive, the _Pragma
> operator has the advantage that it can be used in a macro
> replacement list.
>
> Is _Pragma really a unary operator? If so, does that imply that it can
> only be used in a context that allows a unary expression? That doesn't
> seem to be the intent; rather, it seems that _Pragma should be valid
> anywhere an equivalent #pragma is valid.
>
> Another oddity is that this section is the only one in the standard that
> uses the phrase "unary operator expression"; other sections refer to
> "unary expression".
expressions. So it looks that they used "unary operator expression"
for expressions that are proper to phase 4.
> Wouldn't it be clearer and more consistent to refer to
>
> _Pragma ( string-literal )
>
> as just a sequence of preprocessing tokens, rather than pretending it's
> an expression?
the grammar for phase 4 is missing. It really would be good to have
some, because it has some subtleties that make the grammar different
from the one for later phases.
Jens
James Kuyper
May 15, 2012, 4:58:44 PM5/15/12
to
On 05/15/2012 04:43 PM, Jens Gustedt wrote:
> Am 15.05.2012 06:16, schrieb Keith Thompson:
...
> Am 15.05.2012 06:16, schrieb Keith Thompson:
>> Wouldn't it be clearer and more consistent to refer to
>>
>> _Pragma ( string-literal )
>>
>> as just a sequence of preprocessing tokens, rather than pretending it's
>> an expression?
>
> No, I don't think so. Just the other way round. A full description of
> the grammar for phase 4 is missing. It really would be good to have
> some, because it has some subtleties that make the grammar different
> from the one for later phases.
A.3 gives the grammar for phase 4. It only mentions #pragma, not
>>
>> _Pragma ( string-literal )
>>
>> as just a sequence of preprocessing tokens, rather than pretending it's
>> an expression?
>
> No, I don't think so. Just the other way round. A full description of
> the grammar for phase 4 is missing. It really would be good to have
> some, because it has some subtleties that make the grammar different
> from the one for later phases.
_Pragma() - I guess we're supposed to figure out how _Pragma()
expressions are to be interpreted by first converting them into the
corresponding #pragma directive. Is A.3 incomplete in any other way?
Jens Gustedt
May 15, 2012, 5:18:14 PM5/15/12
to
as if it were an element of the grammar.
"_Pragma" and "defined" are not introduced to the grammar. For _Pragma
this could somehow be captured by "function invocation", but probably
this would restrict the use of it to constant expression, which
doesn't seem to be the intention.
For "defined" this is not so easy since it also may appear just in
operator notation, without parenthesis. Basically the
constant-expression in the #if directive has a different grammar from
what is used for later phases. The grammar of the permitted constant
expressions is only deducible from the descriptive text.
The grammar for the #include directive also seems to be incomplete.
Jens
Keith Thompson
May 15, 2012, 6:15:45 PM5/15/12
to
Jens Gustedt <jens.g...@loria.fr> writes:
> Am 15.05.2012 06:16, schrieb Keith Thompson:
>> N1570 6.10.9p1 says:
>>
>> A unary operator expression of the form:
>> _Pragma ( string-literal )
>> is processed as follows:
>>
>> [explanation deleted]
>>
>> This was added in C99. The C99 Rationale says:
>>
>> As an alternative syntax for a #pragma directive, the _Pragma
>> operator has the advantage that it can be used in a macro
>> replacement list.
>>
>> Is _Pragma really a unary operator? If so, does that imply that it can
>> only be used in a context that allows a unary expression? That doesn't
>> seem to be the intent; rather, it seems that _Pragma should be valid
>> anywhere an equivalent #pragma is valid.
>>
>> Another oddity is that this section is the only one in the standard that
>> uses the phrase "unary operator expression"; other sections refer to
>> "unary expression".
>
> I found one other reference for the term in 6.10.1 for "defined"
> expressions. So it looks that they used "unary operator expression"
> for expressions that are proper to phase 4.
Ok, I missed that.
> Am 15.05.2012 06:16, schrieb Keith Thompson:
>> N1570 6.10.9p1 says:
>>
>> A unary operator expression of the form:
>> _Pragma ( string-literal )
>> is processed as follows:
>>
>> [explanation deleted]
>>
>> This was added in C99. The C99 Rationale says:
>>
>> As an alternative syntax for a #pragma directive, the _Pragma
>> operator has the advantage that it can be used in a macro
>> replacement list.
>>
>> Is _Pragma really a unary operator? If so, does that imply that it can
>> only be used in a context that allows a unary expression? That doesn't
>> seem to be the intent; rather, it seems that _Pragma should be valid
>> anywhere an equivalent #pragma is valid.
>>
>> Another oddity is that this section is the only one in the standard that
>> uses the phrase "unary operator expression"; other sections refer to
>> "unary expression".
>
> I found one other reference for the term in 6.10.1 for "defined"
> expressions. So it looks that they used "unary operator expression"
> for expressions that are proper to phase 4.
But the phrase "unary operator expression" can *very* easily be
confused with "unary expression" (I certainly did) -- and most
unary operators don't require parentheses around their operands.
I think that using that phrase here *without further explanation*
creates more confusion than clarity.
And a _Pragma doesn't *act* like an expression; it doesn't yield
a value, and it can't be used in any context that requires an
expression.
defined(), on the other hand, does act much more like an expression,
though one that's evaluated during preprocessing.
_Pragma really behaves more like a function-like macro that expands
to a #pragma directive -- and macro invocations are not in general
expressions.
Perhaps calling it an expression would make sense in the context of a
more fully described terminology framework, but that framework doesn't
exist.
>> Wouldn't it be clearer and more consistent to refer to
>>
>> _Pragma ( string-literal )
>>
>> as just a sequence of preprocessing tokens, rather than pretending it's
>> an expression?
>
> No, I don't think so. Just the other way round. A full description of
> the grammar for phase 4 is missing. It really would be good to have
> some, because it has some subtleties that make the grammar different
> from the one for later phases.
0 new messages