From J.Reid@letterbox.rl.ac.uk Thu Mar 17 15:20:46 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA28796 (5.65c8/IDA-1.4.4j for ); Thu, 17 Mar 1994 16:21:25 +0100 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Thu, 17 Mar 94 15:21:24 GMT Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id <03606-0@letterbox.rl.ac.uk>; Thu, 17 Mar 1994 15:19:48 +0000 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA04670; Thu, 17 Mar 94 15:20:46 GMT Date: Thu, 17 Mar 94 15:20:46 GMT From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9403171520.AA04670@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Corrigendum 2 ballot, part 1 X-Charset: ASCII X-Char-Esc: 29 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.