From owner-sc22wg5@open-std.org Tue Jan 13 19:28:41 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 2C35EC56D20; Tue, 13 Jan 2009 19:28:41 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mailrelay2.lrz-muenchen.de (mailrelay2.lrz-muenchen.de [129.187.254.102]) by www2.open-std.org (Postfix) with ESMTP id 8E580C178DE for ; Tue, 13 Jan 2009 19:28:39 +0100 (CET) Received: from [129.187.48.213] ([129.187.48.213] [129.187.48.213]) by mailout.lrz-muenchen.de with ESMTP for sc22wg5@open-std.org; Tue, 13 Jan 2009 19:28:09 +0100 Message-Id: <496CDD39.8020800@lrz.de> Date: Tue, 13 Jan 2009 19:28:09 +0100 From: Reinhold Bader Reply-To: Reinhold.Bader@lrz.de User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) 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; format=flowed Content-Transfer-Encoding: 7bit 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