🚀 go-pugleaf

In article 3DL@netcom.com, source@netcom.com (David Harmon) writes:
>
>That reminds me, there is something else that badly needs fixing.
>
>Any #pragma that is not recognized and supported by an implementation
>_must_ generate a diagnostic!  A pragma that had some important meaning
>when the code was written should not be silently ignored when some new
>compiler doesn't spell it the same way.  This is just plain wrong. 

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. If your compiler does not have a
mode where it reports unrecognized pragmas, I would complain to the
vendor.

IMHO, there are a few problems with requiring a diagnostic in the standard.

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

Pragmas are in a sense outside the language. Once you start a line with
	#pragma
the standard has no more to say about the remainder of that logical line.
So what would constitute an error from the standard's point of view?

Suppose the set of arguments you provide to a pragma do not meet some
constraint set by the compiler. Is that an error? If so, how do we word
the standard to say that? If not, what would be an error? Now suppose
an argument is out of range, but the compiler chooses to interpret the
pragma as though you specified a legal value instead. Is that an error?

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

Such program dependencies should not be hidden in pragmas, but should
be made much more obvious. For example, the compiler implementor could
add new keywords to specify particular behavior. Instead of a pragma
to specify different semantics for a standard type (or category of type
like class or enum), the compiler could support new type modifiers as
keywords (e.g. "__near" and "__far" with x86 compilers).

IMHO, pragmas should be reserved for things like turning error reporting
or optimizations on and off. That is, things that don't (necessarily)
affect program correctness, but convenience, efficiency, and the like.
More significant pragmas might have a place in special-purpose compilers,
such as for embedded systems, where programs are inherently unportable.

---
Steve Clamage, stephen.clamage@eng.sun.com




---
[ 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. ]