Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: #pragma
Message-ID: <1988May28.224814.2820@utzoo.uucp>
Organization: U of Toronto Zoology
References: <54080@sun.uucp> <11608@mimsy.UUCP> <7950@brl-smoke.ARPA> <1988May25.212239.1724@utzoo.uucp>
Date: Sat, 28 May 88 22:48:14 GMT

> The basic argument is that the #pragma wording is only a portion of the
> total specification and must not be taken in isolation.  Because a
> conforming implementation must meet EVERY portion of the specification,
> its interpretation of "implementation-defined" in the #pragma wording
> must be constrained by the rest of the Standard...

Unfortunately, this is a convincing argument only if you already believe
the no-semantic-changes-allowed interpretation of #pragma.  One could argue
in a similar way that a string cannot be used to initialize a char array,
because the part of the standard that allows it must surely be constrained
by the rules about type compatibility elsewhere.  The trouble is that this
line of argument cuts both ways:  one cannot interpret the words elsewhere
about aliasing without considering that #pragma might allow exceptions to
be made.  If #pragma cannot be understood in isolation from the rest of
the standard, by the same coin the rest of the standard cannot be understood
in isolation from #pragma.  The rest of the standard constrains #pragma's
effect on aliasing only if you already believe that #pragma is not allowed
to affect the interpretation of the rest of the standard.

What we have here is an out-and-out ambiguity.  There are two plausible
interpretations:  either #pragma is not allowed to alter other parts of
the standard, or it is.  Neither interpretation is self-contradictory.
One can argue over which is more "in the spirit of C", but there is no
way to choose one or the other on the basis of the existing wording.

More to the point, given significant issues like "#pragma noalias", it's
pretty obvious which interpretation implementors will choose.  It seems
to me that they will do this even if the wording is tightened up to require
the other interpretation.  I think it is a bad idea for a standard to try
to play Canute, commanding the tide not to come in.

> Personally I want #pragma out of the standard, but that seems
> unlikely to happen.

Same comment:  the implementors would re-invent it, because IT HAS IMPORTANT
USES.  It's worth standardizing how the effects are invoked even if we can't
say much about the effects themselves.  This makes it easier for compilers
that don't implement "#pragma noalias" to recognize what's going on -- "an
implementation-defined effect that I don't know about is being requested" --
and cope accordingly, e.g. with a warning message.
-- 
"For perfect safety... sit on a fence|  Henry Spencer @ U of Toronto Zoology
and watch the birds." --Wilbur Wright| {ihnp4,decvax,uunet!mnetor}!utzoo!henry