🚀 go-pugleaf

In article <49nbn6$mr5@engnews1.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>This is an interesting point. Many, if not most, compilers will emit
>a warning for unrecognized pragmas, and I would consider it an important
>quality-of-implementation issue. 

Thank you for responding to my cry of anguish.  I interpret the above as 
substantive agreement on the basic issue. 

>Required diagnostics are only for program errors. It is not clear
>to me that an unrecognized pragma should always be considered an error.
>(We are talking about what the standard requires, not optional compiler
>behavior.)

I hope this could be a simple change.  In the ancient ANSI C standard
draft I have, sec. 3.8.6, there is a line that reads "Any pragma that 
is not recognized by the implementation is ignored."  Is that sentence 
still in effect?  If not, then as Emily Latella would say, never mind. 
Otherwise, I just want to see "is ignored" replaced by "causes the
implementation to produce a diagnostic message."  IMO this is merely
correcting a bad decision and not adding any subject matter. 

I agree that a warning is allowed within the meaning of "ignored".  The
compiler can issue a warning for just about anything it wants to; this is
outside the standard.  Nevertheless, I believe that the above wording
"ignored" has contributed to the lousy implementation decision of doing
absolutely nothing.  Maybe it's just my vendor; I assumed it was common. 

I still believe that the most desirable thing is an error diagnostic.
I would settle for a standard that says "has no effect, but will produce a 
warning in any decent implementation." :-)

>So what would constitute an error from the standard's point of view?

Whatever the above "is ignored" currently applies to.  I am perfectly
happy to leave the decision of what pragma is "not recognized" to the
discretion of the vendor.  A "recognized" pragma may even be legally
"ignored".  I just don't want anybody to think that the right thing to 
do about unrecognized pragmas is to silently ignore them, or that that
behavior is mandated. 

>We can find answers to all these questions, but the meta-question is
>whether we want to get into that level of detail in the standard:
>specifying compiler response to extra-linquistic requests.

I don't think I'm asking for any deeper level than what's already there.

>I think the actual problem is not in compilers failing to report unknown
>or invalid pragmas. I think the actual problem is having pragmas that
>matter. Hiding in a pragma something that changes the semantics of a
>program is asking for trouble, IMHO, particularly if the program depends
>for its correctness on a particular set of non-standard semantics.

That goes way beyond the boundaries of my request.  I don't necessarily 
disagree, but how would you specify that in the standard?  A pragma 
should still be allowed to change "implementation defined" behavior.  
I have no desire to open any such can of worms.

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]