From jhauser@jhauser.us Wed Oct 22 09:18:25 2003 Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id h9M7I9Et074804 for ; Wed, 22 Oct 2003 09:18:23 +0200 (CEST) (envelope-from jhauser@jhauser.us) Received: from cordia (12-233-63-221.client.attbi.com[12.233.63.221]) by comcast.net (rwcrmhc13) with ESMTP id <200310220718330150001c8re>; Wed, 22 Oct 2003 07:18:34 +0000 From: "John Hauser" To: Doug Gwyn (CISD) Date: Wed, 22 Oct 2003 00:19:51 -0700 MIME-Version: 1.0 Subject: Re: (embedded-c.183) US-40 CC: embedded-c@dkuug.dk Message-ID: <3F95CD27.18675.379224@localhost> Priority: normal In-reply-to: <200310211918.h9LJIp0D066963@dkuug.dk> References: <200310211904.h9LJ4sDY066804@dkuug.dk> 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 () Doug, 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