From owner-sc22wg5@open-std.org Tue Jan 13 19:43:39 2009 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 5C351C56D20; Tue, 13 Jan 2009 19:43:39 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1209 seconds by postgrey-1.18 at www2.open-std.org; Tue, 13 Jan 2009 19:43:38 CET Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) by www2.open-std.org (Postfix) with ESMTP id 97482C178DE for ; Tue, 13 Jan 2009 19:43:38 +0100 (CET) Received: from fwd07.aul.t-online.de by mailout03.sul.t-online.de with smtp id 1LMnvE-0000Xo-01; Tue, 13 Jan 2009 19:23:28 +0100 Received: from [192.168.2.100] (rIStCZZl8hE-lbKDrwI+L-Y4dpD8bdGNnyEFUMEpAUfGabkdN0VEUngVzE1i2EXg0B@[84.154.76.108]) by fwd07.aul.t-online.de with esmtp id 1LMnuk-1V9SCW0; Tue, 13 Jan 2009 19:22:58 +0100 Message-ID: <496CDC01.70601@lrz.de> Date: Tue, 13 Jan 2009 19:22:57 +0100 From: bader-reinhold@t-online.de (Reinhold Bader) Reply-To: Bader@lrz.de User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 Cc: ISO Fortran Subject: Re: (j3.2006) (SC22WG5.3846) [ukfortran] 09-007/UTI 151 References: <20090112141935.1F12BC178D9@www2.open-std.org> <20090113085334.D8C21C178D9@www2.open-std.org> In-Reply-To: <20090113085334.D8C21C178D9@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ID: rIStCZZl8hE-lbKDrwI+L-Y4dpD8bdGNnyEFUMEpAUfGabkdN0VEUngVzE1i2EXg0B X-TOI-MSGID: 43449fde-ab5a-40aa-a24c-66cd8e53ce88 Sender: owner-sc22wg5@open-std.org Precedence: bulk Hello, Malcolm Cohen schrieb: [...] >> (2) However, I am not sure I understand that any ambiguities actually occur based on >> the bullet list in UTI 151. > I think otherwise, as I tried to explain in the text of the UTI. >> In my opinion, "all-encompassing" pretty much is what >> is intended by the rule since it refers to *use association* only. > I don't agree that the words there convey such an implication (or if > they do, it is a very weak one - too weak in fact). > > ... >> For example take the case of Bullet 1: > ...snipped example that doesn't match what the first bullet says. > >> If I am misunderstanding the bullet list, can someone provide an example >> which demonstrates either an ambiguity or a situation which cannot be checked by the >> compiler? >> > Access via a use-associated pointer that is pointer-associated with the > module entity. As it says, "access via use then pointer association". > Is this allowed? Since the accessibility rules refer to an identifier and not the entity identified (5.3.2 para 1,2), I'd answer this with yes even under the current wording. > I know neither whether it is allowed by the current > wording, nor whether it was intended to be allowed. One might *guess* > that it is supposed to be allowed... but it is not clear to me. > > It's also not clear to me just what this restriction is supposed to be > giving us - since in many cases it looks like one could wriggle around > it (unlike the previous version); that certainly makes it harder to > reason about. Maybe the restriction shouldn't be there at all! In which case a rule like "host access beats use access" would be needed, at least for this particular situation. > Or, if > there is a real problem, maybe we ought not to loosen it after all! > > I don't think it's impossible to get the wording right (whatever "right" > is), but just saying "indirectly" is almost certainly wrong. > > Cheers, -- Dr. Reinhold Bader Leibniz-Rechenzentrum, Abt. Hochleistungssysteme | Tel. +49 89 35831 8825 Boltzmannstr. 1, 85748 Garching | Fax +49 89 35831 9700