Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: Pragmas
Message-ID: <1797@bsu-cs.UUCP>
Date: 7 Jan 88 20:26:11 GMT
References: <8801021358.AA15890@decwrl.dec.com> <1766@bsu-cs.UUCP> <6939@brl-smoke.ARPA>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 27

In article <6939@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 
writes:
>In article <1766@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>>This may not get fixed until a missile is
>>actually lost in space due to a misspelled pragma.
>
>Since a #pragma is not supposed to change the abstract "virtual
>machine" operation, it's hard to see how this could happen.

Consider:  If the programmer used a #pragma at all, he was probably
trying to cause some detectable change in the compilation or execution
of a program.

Perhaps one would use a pragma to tell a compiler to use 32-bit
pointers (say on an 8086 architecture), thus allowing a data-structure
created at runtime, holding coordinates of Soviet missile stations, to
grow to a reasonable limit.  Or ask the compiler to optimize a routine
by unrolling an inner loop so it runs fast enough to keep up with an
anticipated salvo of Soviet missiles, so that one's Star Wars defense
system might work.

The point being that semantically equivalent virtual machines could
still be remarkably different in speed and memory capabilities.  And in
a critical application, an unrecognized pragma might make all the
difference.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi