From J.L.Schonfelder@liverpool.ac.uk Mon Mar 21 09:34:35 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA04195 (5.65c8/IDA-1.4.4j for ); Mon, 21 Mar 1994 10:34:57 +0100 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <05493-0@mailhub.liverpool.ac.uk>; Mon, 21 Mar 1994 09:35:11 +0000 From: "Dr.J.L.Schonfelder" Message-Id: <9403210934.AA18469@uxa.liv.ac.uk> Subject: Re: (SC22WG5.522) Corrigendum 2 ballot, part 1 (fwd) To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Mon, 21 Mar 1994 09:34:35 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3722 X-Charset: ASCII X-Char-Esc: 29 John Reid wrote I would like to support John's view on both these I will be voting NO on 71 and 100 for essentially the same reasons. I have constructed a draft vote, which includes 7 noes. They fall into 2 categories: 1. In 2 cases, I think there is a technical problem. 2. In 5 cases, I think that edi are not needed in the corrigendum, though would probably be appropriate as part of the 95 revision. These are my category 1 noes. Comments, please. John Reid. > > > Y|wc N N865 Item > |_|_| |x| 000071 Use association and common block names > > I am strongly opposed to edit 4. Deleting the last two sentences of > 5.5.2.5 represents a change to the language definition. These sentences > were not put in by accident. A fundamental property of modules is that > an object in a module is defined once only. The intention of the > sentences is to say that if you are accessing variables in a common > block, you must not also redeclare that common block. For example, the > current non-standard practice of placing the common block in a file and > including it can be replaced by placing the common block in a module > and using it. If we allow the common block to be redeclared in a > scoping unit that accesses the module, we get an inconsistency with the > interpretation of an include. > To check 'current practice', I ran the following program on the four > F90 compilers to which I presently have access > module com > common/reid/a > end module com > program main > use com > common/reid/a > a = 1 > write(*,*)a > end program main > All four diagnosed an error. I got a friend to try a fifth and this > issued a warning, but did compile the code and run successfully. > The standard treats host association differently. Here any > object of the host, including any in a common block, may be > inherited provided no entity of that name is declared in the child. > I propose following changes: delete the sentence from 'One of these > cases. ..' and the clause 'and eliminate the ineffective restriction in > 5.5.2.5'; delete edit 4. > > > > > |_|_| |x| 000100 ASSOCIATED intrinsic and zero-sized objects > > This is what Dick Hendrickson said in an email message: > I think the answer for interpretation number 100 is wrong in the way it > treats zero-sized arrays. Basically it says that the ASSOCIATED function > result is UNDEFINED if either POINTER or TARGET is a zero-sized array. > I think this is counter to the intent of the committee when we invented > zero-sized arrays. They were intended to be first-class citizens, just > like zero-sized character strings and zero-trip DO loops, and could be > used anywhere without restriction. It bothers me to think that after > executing > P1 => P2 > that ASSOCIATED(P1,P2) might be undefined. > > I agree wholeheartedly with Dick. I think that the result should be > true if both POINTER and TARGET are of zero size and have the same > type, type-parameters, and shape. I base this on the rule that > zero-sized objects are always defined. We need a similar simple rule, > one that everyone can understand, for the association of zero-sized > pointer targets. This rule will do the right thing in almost every > case. Perhaps there is the occasional case where the programmer will > have to put in a special test, but if the result is undefined, such a > special test will be needed every time there is a possibility of zero > size. > > > > -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk