Article View: mod.std.c
Article #106mod.std.c Digest V8#13
From: Orlando Sotomayor-Diaz
Date: Thu, 18 Jul 1985 19:25
Date: Thu, 18 Jul 1985 19:25
78 lines
3571 bytes
3571 bytes
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Thu, 18 Jul 85 Volume 8 : Issue 13
Today's Topics:
C.3.3.3: unary + vs. unary -
conforming implementation [A.7] (Re: mod.std.c Digest V8#6)
----------------------------------------------------------------------
Date: Thu, 18 Jul 85 11:20:19 EDT
From: ihnp4!seismo!elsie!ado
Subject: C.3.3.3: unary + vs. unary -
To: hou2d!osd
Earlier I noted the difference between descriptions of the effect of unary +
and unary - in section C.3.3.3, page 31:
. . .Except that it inhibits regrouping, the expression +E
is equivalent to (0+E).
. . .The expression -E is equivalent to (0-E).
Mark Brader (hcr!lsuc!msb) has written:
> The standard is correct. Regrouping only takes place where the operators
> are commutative and associative, which binary - is not. Therefore (0-E)
> inhibits regrouping also, and the words "Except that it inhibits regrouping"
> are correctly omitted from the statement regarding -. On the other hand,
> (0+E) does not inhibit regrouping, so the words are correctly included there.
Well. . .suppose that E is (a + (b + c)). If I understand alright, if I write
(0-(a + (b + c))
then this may be (regroupedly) computed as
(0-((a + b) + c))
whereas if I write
-(a + (b + c))
such a regrouping is not allowed. So the second sentence quoted from the draft
above really should be changed to:
. . .Except that it inhibits regrouping, the expression -E
is equivalent to (0-E).
--
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
------------------------------
Date: 14 Jul 85 14:31:38 N (Sun)
From: seismo!mcvax!guido
Subject: conforming implementation [A.7] (Re: mod.std.c Digest V8#6)
To: std-c@cbosgd
>From: John White <mcnc!jnw>
>Subject: conforming implementation [A.7]
>
> But what if, due to the way its implemented, a
>compiler has slightly less strict syntax than the standard requires and
>produces reasonable code when given source using this syntax?
>Adding checks for this situation would make the compiler bigger and slower.
The rule given in the standard requires the error messages because the
program could otherwise be non-portable without the user ever finding out!
(Assuming the user uses the compiler to check the program, not the manual
-- a reasonable assumption, and certainly common practice.)
I would be happy with warnings only, though, and a way to turn specifically
those warnings off that only warn about portability aspects..
Guido van Rossum, CWI, Amsterdam. guido@mcvax.UUCP
------------------------------
End of mod.std.c Digest - Thu, 18 Jul 85 15:23:08 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.
Technical Details
Message-ID:
<611@hou2d.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!decvax!tektronix!uw-beaver!cornell!vax135!houxm!hou2d!osdShow Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83 based; site hou2d.UUCP Path: arc1-ca.pugleaf.net!utzoo!decvax!tektronix!uw-beaver!cornell!vax135!houxm!hou2d!osd From: osd@hou2d.UUCP (Orlando Sotomayor-Diaz) Newsgroups: mod.std.c Subject: mod.std.c Digest V8#13 Message-ID: <611@hou2d.UUCP> Date: Thu, 18-Jul-85 15:25:21 EDT Article-I.D.: hou2d.611 Posted: Thu Jul 18 15:25:21 1985 Date-Received: Fri, 19-Jul-85 20:27:32 EDT Organization: AT&T Bell Labs, Holmdel NJ Lines: 78 Approved: osd@hou2d.UUCP