#pragma

[Steve Summit]

What do people think about #pragmas?  I'm glad ANSI added them; I
think open-ended, extensible interfaces are a great idea (others
may well dislike #pragmas for exactly the same reasons!).  I plan
to make fairly extensive use of #pragmas in any future C tools I
might write, and I'd like to do so in a consistent and compatible
way.  Are there any guidelines or pseudo-standards for #pragma
subsyntax and commonly-named #pragmas?  (I am aware that X3J11
explicitly declined to cover this topic, but it seems like some
less formal standardization mechanism is desirable.)  Has anyone
suggested any kind of a central #pragma registry?

ANSI-anticipating compilers I've seen define #pragmas which to
me seem overly syntax-laden.  For instance, Microsoft's DOS C
compiler has #pragmas like

	#pragma check_stack(on)
	#pragma pack(n)

What are those parentheses for?  I understand the value of
bracketing punctuation for free-form, YACC-like parsers such as
those used for the bulk of C, but for ad-hoc, line-based scanners
such as I'd be inclined to use for parsing #pragma lines, extra
punctuation simply gets in the way.  (It isn't really needed to
disambiguate anything; you just have to step over it if it's
there and generate errors if it's not, which the user doesn't
really appreciate.)

If #pragmas are to be useful and popular, I think it's important
that their syntax be regular and predictable.  If several
implementors have already settled on a de facto standard, I'll
abide by it, but I'm curious to know the rationale (if any).

I'd also like to see #pragma names for common functions
standardized.  For instance, if I write a new, ANSI-compliant
version of lint, I'm going to use #pragmas instead of (well, in
addition to, for backwards compatibility) the special comments
old lint used (/*ARGSUSED*/, /*NOTREACHED*/, etc.).  It would
obviously be unfortunate if different implementations of ANSI
lint picked different names or a different syntax.  I'd propose,
something like the following:

	#pragma lint varargs [n]
	#pragma lint argsused
	#pragma lint notreached
	#pragma lint library

Other tools could make good use of #pragmas, too.  A branch
coverage analyzer could use #pragmas to indicate cases known not
to be exercised by the test suites, and therefore not to be
warned about.  (Robust code typically contains many tests for
"impossible" conditions.)

Going back to #pragmas in general, I'd like to encourage compiler
implementors _not_ to issue warnings in the event of unrecognized
#pragmas, at least as an option.  (I am aware that the dpANS
allows them to do anything they want.)  A single C source file is
likely to be processed by several different compilers, cross-
compilers, and other language tools, and I don't want them all
shouting about each other's #pragmas.  (I'd also rather not
clutter the picture with #ifdefs, which are recommended around
tool-specific #pragmas, i.e. all of them.)

I understand that silently ignoring unrecognized #pragmas is
worrisome, in part because of the problem of mispellings.  (It
took me quite a while to figure out what was going on when I
accidentally typed "#endir" instead of "#endif" under DEC's VMS C
compiler, one version of which ignored unrecognized preprocessor
lines.)  Whether to emit warnings about unrecognized #pragmas
should clearly be an option (I'm not sure what the default should
be).  Additionally, it might be useful if the compiler could be
programmed, via some kind of initialization file or environment
variable, with a list of "known good" #pragma names which are not
to be warned about in any case.  (This was one reason all of my
lint #pragma examples started with the word "lint," so that they
could all be included in one fell swoop.  In fact, a useful
convention would be that all non-compiler language processors
included their name as the first word of any special #pragmas
they defined.  Such prefixes would also help to forestall name
clashes.)

It has been stated that X3J11 has not specified anything (other
than trigraphs) which had not already been implemented in
production compilers.  What was the "prior art" for #pragmas?
(I'm neither doubting nor criticizing the innovation, merely
curious.)

I believe that #pragmas may have been exhaustively discussed in
this group a year or so ago when I wasn't following it.  Feel
free to respond by mail; I'll post the proverbial summary, if
warranted.

                                            Steve Summit
                                            scs at adam.pika.mit.edu