Path: 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

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.