PEPRBV@cfaamp.bitnet (05/14/87)
I recognize that #pragma is non-portable, but most of the C I write only sees one compiler and one machine. It is awkward to set up a makefile which uses different compiler flags for different routines so I would like to be able to put some of these flags in the source code by using #pragma. Examples would be switches to optimize for speed or code size, warnings to the compiler that different pointers point to the same object, so certain optimizations shouldn't be done, turn on stack overflow checking for stack-greedy functions, or force use of a particular memory model. All but the last of these would seem to make sense in any environment, even if the details of what the commands to the compiler are implementation dependent. So, I guess I vote both for compiler writers to implement #pragma commands to control things which could also be command line options, and for ANSI to set some general standards for syntax.
chris@trantor.umd.edu (Chris Torek) (05/23/88)
In article <1988May23.012636.1719@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >... Compilers are required to ignore unrecognized #pragmas >(although I for one think a warning message is in order...) .... >The description [in the dpANS] of #pragma just says "causes the >implementation to behave in an implementation-defined manner". 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. Hence we simply `recognise' it by (in theory) comparing it with a regular expression---to wit, `.*'---and print `#pragma noticed and nothing else done' as our implementation-defined action. -- In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 Domain: chris@mimsy.umd.edu Path: ...!uunet!mimsy!chris
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/24/88)
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. (It used to, before this business was explained to Stallman and crew.) I explained how you need to understand #pragma. 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. It doesn't work for philosophy and it also doesn't work for complex technical specifications. I think #pragma is nearly useless, by the way. Its main use seems to be to enable various listing, (conforming) optimization, and debugging levels, and even that is implementation-specific.
henry@utzoo.uucp (Henry Spencer) (05/26/88)
> I explained how you need to understand #pragma...
You did? Sorry, Doug, I missed that one. Perhaps you would repeat it --
by private mail if you don't want to post again -- as #pragma still looks
absolutely wide open to me. Unless I have made a stupid oversight
somewhere, which is possible, we may have a real problem here. The fact
that there is (last I heard) disagreement among X3J11 about it strengthens
this hypothesis. If #pragma is too subtle for mere mortals to understand
its implications, then it's quite irrelevant whether the truth really is
buried there somewhere, because mere mortals are the ones implementing the
compilers.gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/27/88)
In article <1988May25.212239.1724@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >> I explained how you need to understand #pragma... >You did? Sorry, Doug, I missed that one. Perhaps you would repeat it -- The basic argument is that the #pragma wording is only a portion of the total specification and must not be taken in isolation. Because a conforming implementation must meet EVERY portion of the specification, its interpretation of "implementation-defined" in the #pragma wording must be constrained by the rest of the Standard, which definitely specifies that aliasing is allowed. The key question is obviously, just how much license is granted by the phrase "implementation-defined". There are only a couple of analogous situations in the rest of the proposed Standard, e.g. in 4.9.4.1 it says "If the file is open, the behavior of the `remove' function is implementation-defined." I don't think that was meant to allow an implementation to start running Conway's game of Life, etc. Note that the official definition of "implementation-defined behavior" in 1.6 emphasizes that correct (albeit not strictly conforming) programs CAN rely on implementation-defined behavior, so it is obviously not intended to mean that literally "anything goes". In an ideal programming language designed from scratch, there would be far fewer "implementation-defined" areas. Unfortunately a practical C standard has to depend on such loopholes quite a lot. >If #pragma is too subtle for mere mortals to understand its implications, >then it's quite irrelevant whether the truth really is buried there >somewhere, because mere mortals are the ones implementing the compilers. I think a request that this be clarified would be quite in order. Probably we should not lean so heavily on "implementation-defined", and since the problem seems to occur mainly for #pragma, 3.8.6 is the best place to address it. At least a footnote would seem to be useful. Personally I want #pragma out of the standard, but that seems unlikely to happen.
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
henry@utzoo.uucp (Henry Spencer) (05/29/88)
> The basic argument is that the #pragma wording is only a portion of the > total specification and must not be taken in isolation. Because a > conforming implementation must meet EVERY portion of the specification, > its interpretation of "implementation-defined" in the #pragma wording > must be constrained by the rest of the Standard... Unfortunately, this is a convincing argument only if you already believe the no-semantic-changes-allowed interpretation of #pragma. One could argue in a similar way that a string cannot be used to initialize a char array, because the part of the standard that allows it must surely be constrained by the rules about type compatibility elsewhere. The trouble is that this line of argument cuts both ways: one cannot interpret the words elsewhere about aliasing without considering that #pragma might allow exceptions to be made. If #pragma cannot be understood in isolation from the rest of the standard, by the same coin the rest of the standard cannot be understood in isolation from #pragma. The rest of the standard constrains #pragma's effect on aliasing only if you already believe that #pragma is not allowed to affect the interpretation of the rest of the standard. What we have here is an out-and-out ambiguity. There are two plausible interpretations: either #pragma is not allowed to alter other parts of the standard, or it is. Neither interpretation is self-contradictory. One can argue over which is more "in the spirit of C", but there is no way to choose one or the other on the basis of the existing wording. More to the point, given significant issues like "#pragma noalias", it's pretty obvious which interpretation implementors will choose. It seems to me that they will do this even if the wording is tightened up to require the other interpretation. I think it is a bad idea for a standard to try to play Canute, commanding the tide not to come in. > Personally I want #pragma out of the standard, but that seems > unlikely to happen. Same comment: the implementors would re-invent it, because IT HAS IMPORTANT USES. It's worth standardizing how the effects are invoked even if we can't say much about the effects themselves. This makes it easier for compilers that don't implement "#pragma noalias" to recognize what's going on -- "an implementation-defined effect that I don't know about is being requested" -- and cope accordingly, e.g. with a warning message. -- "For perfect safety... sit on a fence| Henry Spencer @ U of Toronto Zoology and watch the birds." --Wilbur Wright| {ihnp4,decvax,uunet!mnetor}!utzoo!henry
karl@haddock.ISC.COM (Karl Heuer) (06/01/88)
In article <7973@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >Personally I want #pragma out of the standard... I think it should stay in, so that the cretins who like to invent new things like "#module" or "#ident" will have a semi-standard way to do so without interfering with the rest of the world. (At least "#pragma" can be ifdef'd out. "#module" can't%.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint ________ % Unless conforming implementations are required to ignore all unrecognized directives when skipping code--which I think is a bad idea.
v8902477@cc.nu.oz (06/09/90)
Could somebody tell me what #pragma means??? And also what does the sys in #include <sys/types.h> do??? These occured in a program I tried to compile under VAX C and it didn't work. Also VAX C doesn't seem to have <sys/resources.h>. What is this?? Thanks.
jindak@surfside.sgi.com (Chris Schoeneman) (06/11/90)
>Could somebody tell me what #pragma means??? #pragma is the standard way to do non-standard things. For instance, TURBO C uses a #pragma to indicate that a program has inline assembly (otherwise it starts over when it hits the first #asm). Other compilers wouldn't need this, but how do you tell one compiler and not another without changing the code? Use #pragma. Every compiler has different #pragma's so you have to RTFM. >And also what does the sys in #include <sys/types.h> do??? This header defines various machine specific stuff, like how many bits in a byte (NBBY) and data types for the OS. >Also VAX C doesn't seem to have <sys/resources.h>. What is this?? I think what you're looking for is sys/resource.h. Chris Schoeneman | I was neat, clean, shaved and sober, jindak@surfside.esd.sgi.com | and I didn't care who knew it. Silicon Graphics, Inc. | -Raymond Chandler Mountain View, CA | (The Big Sleep)
karl@haddock.ima.isc.com (Karl Heuer) (06/11/90)
In article <2198.2670dea6@cc.nu.oz> v8902477@cc.nu.oz writes: >Could somebody tell me what #pragma means??? Not unless you tell us what was on the rest of the source line, and even then we can only guess what it probably meant on the system for which it was originally written. `#pragma' should always be enclosed in an appropriate `#if', so that it's only visible to the implementations where it makes sense. >And also what does the sys in #include <sys/types.h> do??? It's just part of the name of the header. Often (but not always) it means that the header will be read from a file named `types.h' in a subdirectory `sys' of a directory containing includable files. >These occured in a program I tried to compile under VAX C and it didn't >work. I would tentatively conclude that your implementation is (a) not ANSI compatible (it should have ignored the unknown #pragma) and (b) not POSIX compatible (which requires <sys/types.h> to exist). >Also VAX C doesn't seem to have <sys/resources.h>. What is this?? Assuming you meant that in the singular, <sys/resource.h>, it's a Berkeleyism. Sounds like you're trying to port to VMS something that isn't even portable to Unix. I'd guess you need more help than you can get over the net. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
darcy@druid.uucp (D'Arcy J.M. Cain) (06/11/90)
In article <2198.2670dea6@cc.nu.oz> v8902477@cc.nu.oz writes: >Could somebody tell me what #pragma means??? It means that you should read "The C Programming Language - Second Edition" by Kernigham & Ritchie before posting again. -- D'Arcy J.M. Cain (darcy@druid) | Government: D'Arcy Cain Consulting | Organized crime with an attitude West Hill, Ontario, Canada | (416) 281-6094 |