jgm@k.gp.cs.cmu.edu (John Myers) (05/27/88)
In article <7960@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <2765@umd5.umd.edu> chris@trantor.umd.edu (Chris Torek) writes: >>I took advantage of that clause to make a version of cpp which >>warns about #pragma. The reasoning works as follows: The >>`implementation-defined' manner can be almost anything (GNU cpp >>runs rogue, which appears to be perfectly legal), so long as the >>compiler `recognises' the #pragma. > >The GNU C preprocessor does NOT run rogue when #pragma is >encountered. [...] You cannot understand it while applying >tunnel vision, taking one part of the specification, dropping >its context, and attempting to make sense of what remains by >linguistic analysis. While it may be illegal to exec rogue when #pragma is encountered (the standard needs to be clarified on this point and even then will probably be ignored for the most part--witness the "#pragma noalias" suggestions.), I fail to see how the standard can prohibit an implementation from issuing a warning in this case. As long as the compiler produces output which conforms to the rest of the spec, I see no reason why it can't take the 'implementation-defined' action of generating a warning, as long as the warning is properly worded (i.e. "unsupported pragma" instead of "unrecognized pragma"). The "be quiet on unrecognized pragma" requirement is a tautology: "You're allowed to do something, but if you don't do anything, you have to do nothing." -- _.John G. Myers Internet: John.Myers@cs.cmu.edu LoseNet: ...!seismo!hao!wiscvm.wisc.edu!k!nobody -- _.John G. Myers Internet: John.Myers@cs.cmu.edu LoseNet: ...!seismo!hao!wiscvm.wisc.edu!k!nobody
bts@sas.UUCP (Brian T. Schellenberger) (05/31/88)
In article <1770@pt.cs.cmu.edu> jgm@k.gp.cs.cmu.edu (John Myers) writes: |In article <7960@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: | |While it may be illegal to exec rogue when #pragma is encountered (the |standard needs to be clarified on this point and even then will |probably be ignored for the most part--witness the "#pragma noalias" |suggestions.), I fail to see how the standard can prohibit an |implementation from issuing a warning in this case. I fail to see how running rogue can be illegal if warnings are legal. So long as it spawns a new process to run rogue, and the code produced by the compiler (and interpretation of the rest of the program) does not depend on the results of the rogue game, I can't see how the standard prohibits it. Yes, it's silly, but I still fail to see how it is prohibited. -- --Brian, the man from Babble-on. |Brian T. Schellenberger| ...!mcnc!rti!sas!bts | |104 Willoughby Lane |work: (919) 467-8000 x7783| |Cary, NC 27513 |home: (919) 469-9389 |
jgm@k.gp.cs.cmu.edu (John Myers) (05/31/88)
In article <522@sas.UUCP> bts@sas.UUCP (Brian T. Schellenberger) writes: >In article <1770@pt.cs.cmu.edu> jgm@k.gp.cs.cmu.edu (John Myers) writes: >|While it may be illegal to exec rogue when #pragma is encountered [...] > >I fail to see how running rogue can be illegal if warnings are legal. So long >as it spawns a new process to run rogue, and the code produced by the >compiler (and interpretation of the rest of the program) does not depend on >the results of the rogue game, I can't see how the standard prohibits it. > >Yes, it's silly, but I still fail to see how it is prohibited. There's a subtle nit there: I said 'exec', not 'run'. The GNU C preprocessor used to dump you into some rogue-like game, *aborting* *compilation* when it encountered #pragma. As for the other case, I see nothing in the standard that would prohibit the compiler from spawning a new process to run rogue when it encounters, say, the "int" keyword, as long as it produces correct output. It just so happens that nobody would use such a compiler. Compilers can, do, and should produce warnings for what are perfectly legal C constructs. Whether or not a compiler should produce a warning for "unrecognized" #pragma's depends on what other compilers use it for. Given the various "make it a #pragma" suggestions I have seen, I would think that a warning would be justified. Of course, one should always be able to turn the warning off... -- _.John G. Myers Internet: John.Myers@cs.cmu.edu LoseNet: ...!seismo!hao!wiscvm.wisc.edu!k!nobody "Pascal toting bozos at M***W***" -- Z -- _.John G. Myers Internet: John.Myers@cs.cmu.edu LoseNet: ...!seismo!hao!wiscvm.wisc.edu!k!nobody
scs@adam.pika.mit.edu (Steve Summit) (01/15/89)
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@adam.pika.mit.edugwyn@smoke.BRL.MIL (Doug Gwyn ) (01/16/89)
In article <8770@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >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 don't know who stated that, but it isn't phrased quite right. However, it does happen that #pragma has been implemented in C translators. Some of us just ignore lines "#pragma ..."! That is a valid implementation, and one I heartily recommend. The main source for the notion of pragmas is of course Ada.
henry@utzoo.uucp (Henry Spencer) (01/17/89)
In article <8770@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >... 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... This statement is self-contradictory; #pragmas are implementation-dependent by definition, and any use you make of them will be inconsistent and incompatible with many other implementations. This is not to say you shouldn't use them, but that you should think hard about the tradeoffs. -- "God willing, we will return." | Henry Spencer at U of Toronto Zoology -Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
walter@hpclwjm.HP.COM (Walter Murray) (01/18/89)
Steve Summit writes: > I believe that #pragmas may have been exhaustively discussed in > this group a year or so ago when I wasn't following it. I'm in the same boat. Maybe it's time for someone to post a summary/update on the #pragma question. I have two questions, both of which were probably already addressed. 1. A #pragma causes an implementation to behave in an implementation-defined manner. Could that include, for example, following unsigned-preserving promotion rules, or must the behavior still be ANSI? 2. A strictly conforming program shall not produce output dependent on any implementation-defined behavior. Does it follow that a strictly conforming program shall not use a #pragma? Walter Murray ----------
english@panarea.usc.edu (Joe English) (01/18/89)
In article <1989Jan16.204455.16091@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <8770@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >>... 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... > >This statement is self-contradictory; #pragmas are implementation-dependent >by definition, and any use you make of them will be inconsistent and >incompatible with many other implementations. This is not to say you >shouldn't use them, but that you should think hard about the tradeoffs. Yes, but are there any guidelines, however vague, about what a #pragma line should look like? I liked the original poster's suggestion of #pragma utility-name whatever-garbage-the-utility-wants (e.g., #pragma lint whatever). I think it would be helpful if #pragma's weren't totally implementation-dependent. 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? 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? It would be a boon to developers and programmers alike if there were, I think. /|/| Joe English -----< | | O \|\| english%lipari@oberon.usc.edu
guy@auspex.UUCP (Guy Harris) (01/19/89)
>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.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/19/89)
In article <12570002@hpclwjm.HP.COM> walter@hpclwjm.HP.COM (Walter Murray) writes: >I'm in the same boat. Maybe it's time for someone to post a summary/update >on the #pragma question. There isn't much to tell. #pragma is constrained by the Standard only insofar as it must pass through the preprocessing grammar. I believe several vendors are interested in establishing some additional agreement about how to format #pragma and in setting up some way of registering pragmas in order to avoid conflict among vendors. Such agreements will not be part of the ANSI C standard, however. There may be a special interest group working on this; I don't know. >1. A #pragma causes an implementation to behave in an implementation-defined > manner. Could that include, for example, following unsigned-preserving > promotion rules, or must the behavior still be ANSI? A non-conforming implementation can do whatever it pleases. A conforming implementation must follow ALL the rules in the Standard; permitting implementation-defined behavior in specific circumstances is not to be interpreted as granting license to ignore other relevant specifications. >2. A strictly conforming program shall not produce output dependent on > any implementation-defined behavior. Does it follow that a strictly > conforming program shall not use a #pragma? Only if it affects the output of the program... We actually wanted to say that its "meaning" doesn't depend on any unspecified, undefined, or implementation-defined behavior, but "output" was the best we could come up with in pure standards language. In practice, there is NO portable use of #pragma. A program's output conceivably MIGHT depend on SOME implementation's handling of a #pragma; therefore #pragma ought not to be used in a strictly conforming program (i.e. one intended specifically to be maximally portable). Really, #pragma is intended to give advice to the compiler such as: produce a listing optimize this block in a certain way assign this data to a certain kind of storage It can undoubtedly be made to do many other things, not all of them advisable.
henry@utzoo.uucp (Henry Spencer) (01/20/89)
In article <14744@oberon.USC.EDU> english@panarea.usc.edu (Joe English) writes: >... Are there any guidelines or even hints to developers to >help avoid #pragma namespace conflicts? ... Not in the draft standard; the contents of #pragmas are *totally* left to the implementor. I believe this was a deliberate and carefully-considered decision. -- Allegedly heard aboard Mir: "A | Henry Spencer at U of Toronto Zoology toast to comrade Van Allen!!" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (01/20/89)
In article <12570002@hpclwjm.HP.COM> walter@hpclwjm.HP.COM (Walter Murray) writes: >1. A #pragma causes an implementation to behave in an implementation-defined > manner. Could that include, for example, following unsigned-preserving > promotion rules, or must the behavior still be ANSI? The standard is ambiguous on this point, unless there has been some last- minute wording change I didn't notice. There is an important rule that says you must read a standard as a whole, not take parts of it out of context. That being the case, there are two interpretations: 1. #pragma is constrained by the rest of the standard, and cannot alter its semantics except as provided for by existing "implementation-defined" wording. 2. The rest of the standard is constrained by the presence of #pragma's "implementation-defined" effect, so all bets are off when #pragma appears. Neither of these interpretations is internally contradictory, and it is a near-certainty that most implementors will opt for interpretation 2. >2. A strictly conforming program shall not produce output dependent on > any implementation-defined behavior. Does it follow that a strictly > conforming program shall not use a #pragma? A strictly-conforming program may not depend on any other implementation- defined behavior, so under interpretation 1 such a program can use #pragma safely. Under interpretation 2, you are correct. Under the draft standard and only the draft standard, either interpretation is possible, hence interpretation 2 is possible, hence you are right again. -- Allegedly heard aboard Mir: "A | Henry Spencer at U of Toronto Zoology toast to comrade Van Allen!!" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (01/20/89)
In article <9430@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >Really, #pragma is intended to give advice to the compiler such as: > produce a listing > optimize this block in a certain way > assign this data to a certain kind of storage >It can undoubtedly be made to do many other things, not all of them >advisable. Finally, some one has explained the use of pragma!! In some compilers there may be #pragma ident "string" to add interesting information into a special place in the object and a #pragma debug to cause the compiler to add special symbols for use by the debugger and #pragma optimize off to tell the optimizer to stop optimizing the code for a while In each of the cases the program itself will not change behavior, but the object file could be larger or the program could run slower. The pragma #pragma inline could mimic the C++ inline function construct and is technically legal but gives me a bit of a qualm. -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
w-colinp@microsoft.UUCP (Colin Plumb) (01/21/89)
dlm@cuuxb.UUCP (Dennis L. Mumaugh) wrote: > Finally, some one has explained the use of pragma!! > > In each of the cases the program itself will not change behavior, > but the object file could be larger or the program could run slower. > > The pragma > #pragma inline > could mimic the C++ inline function construct and is technically legal > but gives me a bit of a qualm. Actually, it's still fine. The rule is (roughly) that deleting all #pragma lines from the source should not affect the operation of the resultant executable. One of the worst offenses I've yet seen was a compiler that "ANSIfied" its #asm/#endasm by renaming them #pragma asm and #pragma endasm. Sorry, you should have left them alone. The compiler still would have been conforming, but another compiler would have been able to barf in the right place. -- -Colin (uunet!microsof!w-colinp)
diamond@tkou02.enet.dec.com ("diamond@tkovoa") (11/28/90)
In article <12570055@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >Doug Gwyn writes in response to a note from Norman Diamond: > >>In article <3928@male.EBay.Sun.COM> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: nd>If this is really true, it defeats the purpose of #pragma. My understanding nd>was that #pragma may have any implementation-defined effect WHICH does not nd>change the meaning of a conforming program (though it may change the effect nd>of a nonconforming program). That definition would have been far more useful. dg>That was my argument, but when Walter Murray requested a formal ruling on dg>this, even I had to agree that the wording in the C standard leads to the dg>conclusion that a strictly conforming program cannot use #pragma. su>And that is as it should be. su> su>Consider for a moment if the ANSI committee had adopted something like su>Norman's interpretation: a program must behave the "same" way (whatever su>that is - leave it for the moment) with or without the #pragma. Where would su>that leave, just to take an example, "#pragma ALIGN <something>"? su>Often, such alignment pragmas are required to help programs read binary su>struct images from other machines. Programs which depend on such pragmas su>are, of course, totally non-conforming. su>But if you forbid a pragma from ever having a non-behavior-modifying su>effect, you cannot even implement such a pragma for non-conforming programs su>(because that would make the compiler non-conforming, even though it is su>hard to test for such a situation with any kind of a verification suite). su>If you choose some other method of specifying it (say, "#align <xx>"), su>that also must be diagnosed by a conforming compiler implementation. su>Result: you cannot implement such a mechanism in a conforming compiler su>*at all*. su>Thus the only reasonable approach is to say that a "#pragma" can change the su>behavior of a program in really unspecified ways (unless you want to get su>into the business of standardizing specific pragmas, like Ada does). Not at all. A program which wants to be conforming and executable on all implementations, but obtain some feature from an implementation which recognizes a particular #pragma, should use #pragma. A program which DEPENDS on a non-portable construction should use an extended #directive and/or __identifier that is offered by the particular implementation. This is exactly why the standard says that if an implementation does not recognize a particular #pragma, it should ignore it. If an implementation does not recognize a #funny_directive or __reserved_identifier, it is supposed to issue a diagnostic. Implementation-dependent programs that are coded in Mr. Unni's style will not receive the desired diagnostics from other implementations. The instructions that an unrecognized #pragma be ignored are now either useless or, worse, counterproductive. Unfortunately, the ANSI committee seems to have forgotten their own wishes. -- Norman Diamond, Nihon DEC diamond@tkov50.enet.dec.com (tkou02 is scheduled for demolition) We steer like a sports car: I use opinions; the company uses the rack.
sue@hprsue.HP.COM (Sue Meloy) (11/30/90)
Norman Diamond writes: > Not at all. A program which wants to be conforming and executable on all > implementations, but obtain some feature from an implementation which > recognizes a particular #pragma, should use #pragma. A program which > DEPENDS on a non-portable construction should use an extended #directive > and/or __identifier that is offered by the particular implementation. > > This is exactly why the standard says that if an implementation does not > recognize a particular #pragma, it should ignore it. If an implementation > does not recognize a #funny_directive or __reserved_identifier, it is > supposed to issue a diagnostic. Implementation-dependent programs that > are coded in Mr. Unni's style will not receive the desired diagnostics > from other implementations. > > The instructions that an unrecognized #pragma be ignored are now either > useless or, worse, counterproductive. Unfortunately, the ANSI committee > seems to have forgotten their own wishes. There are still pitfalls even with #pragma. Just because an implementation "recognizes" the pragma does not mean that it will do what the programmer intends. One implementation may interpret #pragma list to mean that a program listing should be generated, while another could interpret this to mean that this month's accounts payable transactions should be dumped to the line printer. The only safe thing is for all implementation-specific directives to be protected by ifdefs. Thus, a conforming program can contain pragmas which could affect the behavior of a strictly conforming program, but can continue to be compiled on an implementation that does not make use of those pragmas. For example (no noalias diatribes, please!), do_something(int *vector1, int *vector2) #ifdef WHIZBANG_C #pragma noalias vector1,vector2 #endif { /* do some stuff that could be vectorized if vector1 and vector2 * are not aliased to one another. */ } If WHIZBANG_C is not defined, this code must be accepted and run as specified by the standard on all conforming implementations. Whether it does the right thing on WHIZBANG_C is a quality-of-implementation/ quality-of-programmer issue. This brings up another question: If a non-standard directive name is used instead, is a conforming implementation required to accept it if it appears inside a skipped section of code? The standard does not appear to be completely clear on this point; it says that in this case "... directives are processed only through the name that determines the directive in order to keep track of the level of nested conditionals...". My gut feel is that even this limited amount of processing would require a diagnostic if the directive name is not standard. Sue Meloy sue@hpcllca.cup.hp.com
chris@mimsy.umd.edu (Chris Torek) (12/01/90)
In article <12570056@hprsue.HP.COM> sue@hprsue.HP.COM (Sue Meloy) writes: >The only safe thing is for all implementation-specific directives >to be protected by ifdefs. (sounds good to me) >For example (no noalias diatribes, please!), Why not? :-) >do_something(int *vector1, int *vector2) >#ifdef WHIZBANG_C >#pragma noalias vector1,vector2 >#endif I still think `noalias' is a horrible name. For those who want to build compilers without automatic alias detection (which is, I admit, both impossible in general and very slow in the usual possible cases), I suggest the syntax noninterfering(p1, p2, p3, ..., pn) which means that stores through p1 do not `interfere' with indirection through any of p2, p3, ..., pn; stores through p2 do not interfere with indirection through p1, p3, ..., pn; ...; and stores through pn do not intefere with indirection through p1, p2, ..., pn. Note that this is a weaker restriction. It should probably be augmented to take functions as well: noninterfering(p1, munch) would say that munch() never affects p1[i] for any legal i (and, equivalently, that p1[i] never affects munch()). With a special syntax (ick) this same declaration could declare a pointer or function `pure': noninterfering(sin, *) # sin(x) is a pure function noninterfering(ptr, *) # ptr points to memory not affected by # any other pointer or function It is not clear how to indicate that second-level pointers are pure. Something along the lines of double **x; #pragma noninterfering(x, x[*], *) might declare that not only is x[i] `pure', but also x[i][j]. This syntax could almost certainly be improved. Oh well, enough of this. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
steve@taumet.com (Stephen Clamage) (12/03/90)
sue@hprsue.HP.COM (Sue Meloy) writes: >The only safe thing is for all implementation-specific directives >to be protected by ifdefs. Thus, a conforming program can >contain pragmas which could affect the behavior of a strictly conforming >program, but can continue to be compiled on an implementation that does not >make use of those pragmas. Yes, indeed. Someone posted a question a while back asking about the meaning of "#pragma once". My favorite reply was that it turned on some special features for use by the customer engineer -- there would also be a "#pragma offce" to disable the special features. -- Steve Clamage, TauMetric Corp, steve@taumet.com
diamond@tkou02.enet.dec.com ("diamond@tkovoa") (12/03/90)
References: <9011272328.AA03163@decpa.pa.dec.com> <12570056@hprsue.HP.COM> Reply-To: diamond@tkov50.enet.dec.com (Norman Diamond) In article <12570056@hprsue.HP.COM> sue@hprsue.HP.COM (Sue Meloy) writes: >Norman Diamond writes: >> Not at all. A program which wants to be conforming and executable on all >> implementations, but obtain some feature from an implementation which >> recognizes a particular #pragma, should use #pragma. A program which >> DEPENDS on a non-portable construction should use an extended #directive >> and/or __identifier that is offered by the particular implementation. >There are still pitfalls even with #pragma. Just because an implementation >"recognizes" the pragma does not mean that it will do what the programmer >intends. Earlier in this thread, I pointed out that if ANSI had stuck to its original intention, that #pragma be unable to change the meaning of a conforming program (though of course be able to change the meaning of an unconforming program), then a conforming program could use #pragma to obtain a benefit (optimization or whatever) on one implementation, but would still work correctly (though without that benefit) on other implementations. Sure, if a #pragma causes pessimization and no diagnostic on the machine that you're porting to, then you have a pitfall, but THE PROGRAM WOULD STILL WORK CORRECTLY. ANSI's change-of-mind now denies this portability. >One implementation may interpret #pragma list to mean that >a program listing should be generated, while another could interpret this to >mean that this month's accounts payable transactions should be dumped to >the line printer. In ANSI's original intent, these could be compile-time results, but not execution-time. An execution of the program would still have to have the effect defined by the standard. However, in ANSI's new intent, yes these could be execution-time results too. Very unfortunate. >If a non-standard directive name is used instead, is a conforming >implementation required to accept it if it appears inside a skipped >section of code? [...] My gut feel is that >even this limited amount of processing would require a diagnostic if >the directive name is not standard. Mine too. A non-standard directive name violates the BNF-like syntax and must produce at least one diagnostic (unless this rule applies only to the ordinary, non-preprocessor BNF). There does not appear to be any exemption for one that is in a skipped section of code. -- Norman Diamond, Nihon DEC diamond@tkov50.enet.dec.com (tkou02 is scheduled for demolition) We steer like a sports car: I use opinions; the company uses the rack.
gwyn@smoke.brl.mil (Doug Gwyn) (12/03/90)
In article <9012030445.AA04437@decpa.pa.dec.com> diamond@tkou02.enet.dec.com ("diamond@tkovoa") writes: >... if ANSI had stuck to its original intention, ... >ANSI's change-of-mind now denies this portability. >In ANSI's original intent, ... >However, in ANSI's new intent, ... I think a large fraction of X3J11 would deny that their original intention was that #pragma could not affect semantics. Certainly the final standard allows it to.
diamond@tkou02.enet.dec.com ("diamond@tkovoa") (12/05/90)
In article <14641@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >I think a large fraction of X3J11 would deny that their original intention >was that #pragma could not affect semantics. Certainly the final standard >allows it to. In that case, why should unrecognized #pragmas be ignored? If their original intent was that programs could depend on #pragma to obtain correct results (correct for the program), then they would have specified that unrecognized #pragmas draw diagnostics. This seems very strange. OK, in some contexts, it has been suggested that the standard does not forbid an implementation to produce extraneous, even misleading, diagnostics for a conforming program, as long as it executes the program correctly. Thus, can a quality implementation produce a quasi-extraneous, non-misleading diagnostic for an unrecognized #pragma? There is additional context here, that unrecognized #pragmas are required to be ignored. Is quality even permitted here? -- Norman Diamond, Nihon DEC diamond@tkov50.enet.dec.com (tkou02 is scheduled for demolition) We steer like a sports car: I use opinions; the company uses the rack.
karl@ima.isc.com (Karl Heuer) (12/06/90)
In article <9012050330.AA04857@decpa.pa.dec.com> diamond@tkou02.enet.dec.com ("diamond@tkovoa") writes: >In that case, why should unrecognized #pragmas be ignored? I agree that this was a bad idea. >[Is it okay to produce a diagnostic?] There are two available loopholes. One is to say "there are no unrecognized #pragma directives for us to ignore, because our implementation interprets all forms of #pragma as a valid request to terminate the compilation." This is what gcc used to do (with embellishments that some found amusing), but the FSF was pressured to change this. (I rather liked it.) The other approach is to emit the diagnostic "warning: unrecognized #pragma" and continue compilation. This is completely legal (as are all warnings%), and I consider such an implementation to be higher quality than one which does not do so. Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint ________ % including such things as "comment does not match code" :-)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/06/90)
In <9012050330.AA04857@decpa.pa.dec.com> diamond@tkou02.enet.dec.com ("diamond@tkovoa") writes: >In that case, why should unrecognized #pragmas be ignored? A minor mistake. Pragmas allow one to escape from the confines of the standard. Such escapes should always be done under the full control of the user. A good way to implement pragmas is to require that all pragmas that will be recognized by a compiler be listed in a file, and any pragma not in that file result in a warning. This will minimize the probability that a switch in compilers, or a revision in the names of pragmas interpreted by a compiler, won't cause surprises. The current situation, such that some pragmas are silently obeyed, while others are silently ignored, is a disaster waiting to happen. /* The "unroll-loop" pragma force loop unrolling, so our process will react well within the 0.5 milliseconds needed to avoid a nuclear explosion. */ #pragma unrolll_loop /* Darn! Got to get that keybounce fixed */ -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi