Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: Pragmas Message-ID: <506@cresswell.quintus.UUCP> Date: 4 Jan 88 08:54:09 GMT References: <8801021358.AA15890@decwrl.dec.com> <504@cresswell.quintus.UUCP> <1988Jan3.162343.1697@jarvis.csri.toronto.edu> Organization: Quintus Computer Systems, Mountain View, CA Lines: 91 In article <1988Jan3.162343.1697@jarvis.csri.toronto.edu>, flaps@dgp.toronto.edu (Alan J Rosenthal) replied my message about #pragma: > How about having the preprocessor just pass them through? The compiler > and the preprocessor already agree on how some lines beginning with # > are passed through, namely the "# line file" lines. Just typing > "/lib/cpp" gives me one. /lib/cpp will also pass them through. Passing #pragmas through to the compiler means that (1) /lib/cpp has to parse stuff which is significant to the C compiler, and ONLY to the C compiler. (2) /bin/cc has to parse something like the pragma(..) construct ANYWAY, the user just doesn't get told what it looks like (and so doesn't know how to *avoid* it). #line is a different case. The whole POINT of the preprocessor is to drop lines, expand macros, and generally do all sorts of things that can make it hard for the compiler to work out where anything came from. In fact, as your example shows, the main function of # is not to be passed through by the preprocessor, but to be generated by the preprocessor. I have never written a # in my life, but the preprocessor has made millions for me, BECAUSE THAT IS PART OF ITS JOB. (And it can be told not to. Try /lib/cpp -P) #line is **related to cpp's FUNCTION**. #pragma is not related to the function of the *preprocessor*. If you are going to pass #pragmas through to the compiler in some fashion, why not reserve one (count them, ONE) keyword for the thing that gets passed through, and standardise that? Something of the sort apparently has to be around anyway, and having just one keyword makes it easy to avoid. Perhaps I can make it a little bit clearer why, if pragmas are going to be in the language, having pragma(system-dependent-parenthesis-balanced-stuff) as something that can appear where 'noalias' would have been allowed, is a better way to go than having #pragma in the pre-processor. One of the things one wants to do with a program is to analyse it. For example, one would like to produce cross-referencers, static call graph analysers, "software metrics" tools, &c &c. We would like to write such tools ONCE for "ANSI C". The easiest way to hack this is cc -E source.c | analyser which means that your analyser doesn't have to be a preprocessor as well as a parser! The # lines generated by the preprocessor tell you everything you need to know about where things came from (if you are doing a cross referencer or dependency analysis). If the "pragma" construct is defined as pragma(..) in the compiler language, then each tool has to be prepared to skip a parenthesis balanced sequence of tokens after pragma() but can otherwise ignore the construct. But if #pragma is a pass-through (as some quite undocumented form) then I can't defend my tool against it, because I don't know what the passed-through form is going to look like. Now the ANSI committee has rightly chosen not to specify the behaviour of the preprocessor as a separate program, or even that it IS a separate program, or even that "cc -E" should work. But they surely should not go out of their way to make life hard for people who want to write program analysis tools! > After ANSI standard C hits the streets, when you type "man cc", it will > probably have a section describing pragmas, or at least it should. It I have access to a compiler NOW on a S5.3 machine that has #pragma. The manual does NOT tell me what #pragma does. > will say something like "'#pragma device_register id' means that the > next occurrence of 'id' is a device register". Or wherever it was you > learned of the pragma's meaning in the first place. No problem. Yes, that will answer the "scope" problem. But my actual viewpoint is that I would like to be able to write tools that will work in the presence of pragmas(), without even having heard of the machine or its operating system, let alone having seen the compiler manual. I can do this for ADA. Why not for C? > Two further comments on this: > 1. that's a terrible construct anyway. > 2. I can't think of your three other "natural" interpretations. Two rejoinders: (1) #pragma device_register fred was *your* example. I merely pointed out the problem. (2) Thank you. I was hoping for that. I bet there are at least three implementors out there who also can't think what the three "other" interpretations are, and yours is one of the ones they can't think of. Which is why #pragma ; IS a terrible construct.