From hirchert@ncsa.uiuc.edu Mon Apr 18 07:29:58 1994 Received: from newton.ncsa.uiuc.edu by dkuug.dk with SMTP id AA26786 (5.65c8/IDA-1.4.4j for ); Mon, 18 Apr 1994 19:30:16 +0200 Received: from landrew.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA16141 (5.65a/IDA-1.4.2 for sc22wg5@dkuug.dk); Mon, 18 Apr 94 12:30:06 -0500 Return-Path: Received: by landrew.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA01156; Mon, 18 Apr 94 12:29:58 CDT Date: Mon, 18 Apr 94 12:29:58 CDT From: hirchert@ncsa.uiuc.edu (Kurt W. Hirchert) Message-Id: <9404181729.AA01156@landrew.ncsa.uiuc.edu> In-Reply-To: Jeanne T Martin's message of Mar 10, 14:01 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: martin@ocfmail.ocf.llnl.gov (Jeanne T Martin) Subject: Re: (SC22WG5.518) Ballot on corrigendum 2 Cc: sc22wg5@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 I vote yes on all items, with the following comments: 000071 Y Hirchert The objections to this item appear to be based on the notion that this interpretation is allowing something accessed by use association to be redefined or redeclared. This notion is wrong: The common block (and its mapping) is _not_ made accessible by use association. Variables in the common block may be made accessible, but that may or may not be the entire common block. Since the common block mapping is _not_ an entity made accessible, there is nothing wrong with defining that mapping in the new scoping unit. Note that the restriction, as written, prevents access even if no variables from the common block are accessed. Indeed, it prevents access even if no variables could be accessed because they are all private. Such an interaction with the private portions of a module is entirely inconsistent with rest of the rules for modules. 000100 Y Hirchert I appreciate the unease about the handling of zero-size arrays, but I am afraid that any defined value for ASSOCIATED in these cases will be inconsistent with the limit of the non-zero cases. (I.e., these limits are themselves _inconsistent_.) 000151 Y Hirchert I agree with Lawrie that it was not our intent to preclude operators on pointers. However, the work necessary to allow them appears to require doing things that also were not our intent. I conclude that we should interpret the document as it stands on this point (disallowing pointer operators), but make fixing this matter a requirement for F95. -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications