Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!mailrus!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: #pragma does only half the job (was Re: Pragma and noalias)
Message-ID: <519@proxftl.UUCP>
Date: 22 Jul 88 12:11:30 GMT
References: <502@proxftl.UUCP> <381@proxftl.UUCP> <8176@brl-smoke.ARPA> <423@proxftl.UUCP> <23349@think.UUCP> <437@proxftl.UUCP> <1988Jul10.201104.27556@utzoo.uucp> <4580@pasteur.Berkeley.Edu>
Reply-To: bill@proxftl.UUCP (T. William Wells)
Organization: Proximity Technology, Ft. Lauderdale
Lines: 28
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <4580@pasteur.Berkeley.Edu> faustus@ic.Berkeley.EDU (Wayne A. Christopher) writes:
> In article <502@proxftl.UUCP>, bill@proxftl.UUCP (T. William Wells) writes:
> > "[a pragma] causes the implementation to behave in an
> > implementation-defined manner...."
> >
> > My reading of this says that a pragma changes the implementation,
> > not (directly) the interpretation of the program.  However, the
> > changed implementation must also be conforming.
>
> You're right, this statement is sort of confusing, but when you think
> about it, it has to mean that #pragma can cause a compiler to become
> non-conforming.  Otherwise, #pragma noalias wouldn't be possible.
> Telling the compiler that a set of parameters is noalias changes the
> semantics of the function.

Perhaps you came in late on this debate?  The whole point of it
is whether the standard DOES allow the use of #pragma to specify
noalias (and friends).  The reading I give to it prohibits this;
other readings permit it.

Reading 1: #pragma modifies the implementation.  #pragma noalias
    is not permitted.

Reading 2: #pragma modifies the program.  Anything goes,
    including #pragma noalias.

And, as I said, this ought to be clarified for the next draft
standard.