Article View: comp.std.c
Article #2033Re: #pragma
From: diamond
Date: Mon, 03 Dec 1990 04:54
Date: Mon, 03 Dec 1990 04:54
45 lines
3106 bytes
3106 bytes
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.
Technical Details
Message-ID:
<9012030445.AA04437@decpa.pa.dec.com>Path:
arc1-ca.pugleaf.net!utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!tkou02.enet.dec.com!diamondShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!tkou02.enet.dec.com!diamond
From: diamond@tkou02.enet.dec.com ("diamond@tkovoa")
Newsgroups: comp.std.c
Subject: Re: #pragma
Message-ID: <9012030445.AA04437@decpa.pa.dec.com>
Date: 3 Dec 90 04:54:14 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 45