#pragma

Guy Harris guy at auspex.UUCP
Thu Jan 19 05:16:26 AEST 1989


>Order of evaluation of certain expressions is also
>"implementation-dependent," and the clear message is not to count on it
>under any circumstances.  Is the same to be true of #pragma's?

No.

Order of evaluation (with some exceptions), and the order in which side
effects take place, are both unspecified (section 3.3, May 13, 1988
draft).

The behavior caused by a "#pragma" is implementation-DEFINED (section
3.8.4, May 13, 1988 draft).

It's conceivable that the wording may have changed in a subsequent
draft; however, if not, the difference between "unspecified" and
"implementation-defined" is significant.

"Unspecified behavior" is "behavior, for a correct program construct and
correct data, for which the Standard imposes no requirements."

"Implementation-defined behavior" is "behavior, for a correct program
construct and correct data, that depends on the characteristics of the
implementation *and that each implementation shall document*." 
(Emphasis added.)

This means that no manual that came with your C compiler need say what
the order of evaluation of those expressions is; even if it did, it may
not be able to say so in a simple fashion, so you might have no way of
counting on it even if it *is* documented, in some sense. 

It also means that some manual that comes with your C compiler (or some
other form of documentation) must say what the #pragmas that the
compiler supports are, and what they do.

This means that you (meaning "you, the application writer writing an
application in C that may use #pragmas") *can* count on #pragmas, as
long as:

	1) you compile your source only on systems where you know the
	   #pragma in question does what you want it to do

or

	2) you protect it with #ifdefs that will ensure that the
	   compiler only sees it on such implementations, or use some
	   other trick to ensure that (e.g., having a "pragmas.h"
	   include file in your source, and having different versions of
	   it for different environments).

>At the very least, I'd like to not have to worry that my #pragma gnuc's
>will conflict with my #pragma lint's and #pragma turboc's.  Are there
>any guidelines or even hints to developers to help avoid #pragma
>namespace conflicts?

(I presume that "developer" means "developer of a C compiler" rather than
"developer of an application".)  No, I know of such guidelines or hints.



More information about the Comp.std.c mailing list