From jhauser@jhauser.us Fri Feb 27 00:13:40 2004 Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id i1QNDb1S083022 for ; Fri, 27 Feb 2004 00:13:38 +0100 (CET) (envelope-from jhauser@jhauser.us) Received: from cordia (c-24-7-96-152.client.comcast.net[24.7.96.152]) by comcast.net (rwcrmhc13) with ESMTP id <2004022623140001500o7165e>; Thu, 26 Feb 2004 23:14:01 +0000 From: "John Hauser" To: Embedded-C Date: Thu, 26 Feb 2004 15:15:03 -0800 MIME-Version: 1.0 Subject: Repeat: US-40 Message-ID: <403E0D77.10314.4E0911@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Spam-Score: 0 () Okay, rather than make everybody search for embedded-c.184, I've attached it below. This issue really needs fixing, too, ASAP. - John Hauser ---------- message embedded-c.184 from John Hauser: Take three: On further reflection, I've noticed that a couple of the statements concerning effective types in 6.5 of the C Standard are not exactly correct in the presence of address-space qualifiers. The easiest fix is probably to modify the concept of _effective type_ so as not to include an address-space qualifier. (The whole concept of _effective type_ is used only in 6.5 and in one footnote elsewhere in the C Standard.) This can be done by changing the first two sentences of paragraph 6 of 6.5 to be The _effective type_ of an object for an access to its stored value is the declared type of the object, if any, without any address-space qualifier that the declared type may have.[72] If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue, minus any address-space qualifier, becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If this were done, then (I think) no other changes would be needed for 6.5---my previous suggestion to modify the second and fourth bullets would be voided. As discussed earlier, the definition of _additionally access-qualified_ in 6.2.5 could also be dropped as it would no longer be used. All of these edits I'm speaking of are, or course, intended to be reflected in the "detailed changes" of 3.3 of the TR. Doug, do you see any problems with this proposed fix? - John Hauser