Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!bfmny0!tneff From: tneff@bfmny0.UUCP (Tom Neff) Newsgroups: comp.std.c Subject: Re: I can't find a good definition anywhere... Message-ID: <14324@bfmny0.UUCP> Date: 13 May 89 14:44:53 GMT References: <1954@trantor.harris-atd.com> <10084@smoke.BRL.MIL> <1339@ncr-sd.SanDiego.NCR.COM> <10214@smoke.BRL.MIL> <849@mtxinu.UUCP> <2810@buengc.BU.EDU> <13022@haddock.ima.isc.com> <10253@smoke.BRL.MIL> <1989May12.154810.21589@ Reply-To: tneff@bfmny0.UUCP (Tom Neff) Organization: ^ Lines: 55 In article <1989May12.154810.21589@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <10253@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>There is some sentiment that whatever #pragma does, the rest of the >>specifications in the Standard still have to be conformed to, so it's ^^^^^^^^^^^^^^^^^^^^^ That is, in order for the resulting program to remain ANSI conformant... >>not quite "anything". Valid examples are output listing control, >>levels of optimization, etc. > >Unfortunately, while there is some sentiment for this view, it's not >guaranteed by the Standard (unless the relevant text has changed since >the October draft), so it should not be relied on. There are two >possible interpretations of the actual wording, neither of which is >internally contradictory: either #pragma is allowed to change the >rules, or it isn't. Opinions vary on which interpretation is preferable, >but the Standard doesn't say. I don't think there's any doubt whatsoever that #pragma cannot be used to "change the rules" in the sense that saying something like #pragma operator_precedence(+/*-.[]->) would yield a *valid ANSI C* program whose operator precedence differed radically from the Standard. My reading of the draft suggests that you are allowed to put anything you want in a #pragma and still have a valid ANSI C program *so long as the rest of the source would be valid ANSI C anyway.* That's why output listing control and optimization are the "friendliest" examples. Less friendly are things like #pragma allow_our_weird_extended_keywords=YES which then allows statements like extern void massively_parallel testfunc(int a); or shared char *mydata; to compile. Implementors are certainly going to do this, since #pragma is a very natural facility for it. (I think MS already does to some extent.) The question is, is the resulting *program* ANSI C? Not at all -- #pragma was used to break conformance. It'll be a rare implementation where this isn't possible one way or another, if only because every compiler has predecessors from the same vendor who will want a safety valve for backward compatibility. Is a compiler that's *capable* of compiling a non-conformant program via #pragma, but is also capable of compiling conformantly otherwise, still allowed to define _STDC_ 1? Yes! if the killer #pragma isn't in effect. I think this is what Henry's really asking. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET