PC File: 95-006a4.150 Archive: 95-006r4.A150 -------------------------------------------------------------------------------- NUMBER: 000154 TITLE: EQUIVALENCE and zero-sized sequences KEYWORDS: EQUIVALENCE statement, zero-sized sequences DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 5.5.1 and its subsections discuss equivalence association and zero-sized sequences, but not in detail sufficient to answer the following questions: Given the following CHARACTER (LEN=4) :: A, B, C Question 1: are the following equivalence statements valid? COMMON /X/ A COMMON /Y/ B EQUIVALENCE (A, C(10:9)), (B, C(10:9)) ! the same zero-sized object is ! equivalenced to two different ! common blocks. EQUIVALENCE (A, C(10:9)), (B, C(100:90)) ! two different zero-sized objects ! are equivalenced to two different ! common blocks Question 2: is the following equivalence valid EQUIVALENCE (C, C(10:9)) Question 3: Is the following valid? EQUIVALENCE (C(10:9), C(100:90)) Question 4: It is generally the case that given CHARACTER (LEN=4) :: D, E, F then EQUIVALENCE (D, E) EQUIVALENCE (F, E) and EQUIVALENCE (D, E, F) both specify that D is equivalenced to F. Do the following specify the same storage associations? EQUIVALENCE (D, E(2:1)) ! E(2:1) is zero sized EQUIVALENCE (F, E(2:1)) and EQUIVALENCE (D, E(2:1), F) EQUIVALENCE (D, E(2:1)) ! E(2:1) is zero sized EQUIVALENCE (F, E(3:1)) ! E(3:1) is also zero-sized and EQUIVALENCE (D, E(2:1), F) Question 5: is E(2:1) a subobject of E? ANSWER 1: Both equivalence statements are invalid. In section 5.5.1.1 [57:21-22], the standard states that all zero sized sequences in the are storage associated with each other, and with the first storage unit of any non-zero sized sequences. In section 14.6.3.2, the standard states that two storage units that are associated with the same zero sized storage sequence are the same storage unit. In the first equivalence statement in question 1, both A and B are storage associated with the same zero sized storage sequence, namely C(10:9), therefore, A and B are storage associated, which is prohibited, since they are declared in different common blocks. In the second equivalence statement in question 1, the standard is unclear about whether C(10:9) and C(100:90) are the same zero-sized storage sequence. An edit is supplied to clarify this case. Since C(10:9) and C(100:90), are the same zero-sized storage sequence, the second equivalence statement in question 1 is illegal because the equivalence statement declares A and B to be storage associated, but they are declared in different common blocks. ANSWER 2: Yes. ANSWER 3: Yes. ANSWER 4: Yes. ANSWER 5: Yes. EDIT: In section 14.6.3.2 [248:15], after the last sentence in the second paragraph, add "Two zero-sized subobjects of the same object are the same zero sized storage sequence.". SUBMITTED BY: Dick Weaver HISTORY: 93-264 m127 submitted 93-323 m127 response approved 14-5 94-034 m128 X3J3 ballot failed 10-18 -------------------------------------------------------------------------------- NUMBER: 000155 TITLE: Multiple USE statements, rename and only lists. KEYWORDS: USE statement, use renaming, ONLY DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 11.3.2 states: (with some formatting to better show logic, tags added to assist references): R1109 is or [ =>] Constraint: Each must be a public entity in the module. Constraint: Each must be the name of a public entity in the module. ...... More than one USE statement for a given module may appear in a scoping unit. If one of the USE statements is without an ONLY qualifier, (a) all public entities in the module are accessible and (b) the s and s are interpreted as a single concatenated . Questions: 1. Is the syntax ambiguous? Note: R1107 is USE [,] or USE , ONLY: [] R1109 is or [ =>] R522 is or Thus in an can parse either as R1109 or R1109 -> R522 . 2. Can s and s be concatenated as a as specified in (b)? s permit "", while rename lists require " => ". ANSWER: 1. Yes. The syntax is ambiguous ("" should be changed to ""). However removal of the ambiguity will be deferred to the next revision of the standard (Fortran 95). 2. No. Rename and only lists cannot be concatenated as a , however the "renames" in both lists can. An edit is supplied to correct this. Discussion: There are many other places in the standard besides R1109 where the same interpretation can be reached by more than one path through the syntax (e.g. could be removed from R533 since it is a special case of a ). Rather than fix this one ambiguity now, it will be deferred to the more general clean up in Fortran 95. Note that in Fortran 95 the appropriate edits to remove the ambiguity in R1109 are : 1. In section 11.3.2, R1109 [158:11] change "" to "" 2. In section 11.3.2, the first constraint following R1109 [158:13] change "" to "" 3. In section 11.3.2, paragraph beginning "A USE statement" [158:19] change "s" to "s" EDITS: In section 11.3.2, paragraph beginning "More than one" [158:22-23] change "s and s" to "s and renames in s" SUBMITTED BY: Dick Weaver HISTORY: 93-265 m127 submitted 93-305 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 failed WG5 ballot 94-352 m131 revised response, approved u.c. 95-034r1 m132 X3J3 ballot failed 19-1 -------------------------------------------------------------------------------- NUMBER: 000158 TITLE: Leftmost (on a line) negative integer KEYWORDS: integer - negative, negative integer, conformance DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: In many computers today the range of values for integer types is not symmetric. Consider, for example, a machine with 8-bit integer arithmetic (to keep the numbers small). The integer range would typically be -128 to +127 Given an implementation that specifies an integer type with that range, do the following statements conform to Fortran 90? DATA I /-128/ I = - 128 ANSWER: The data statement is NOT VALID. r530 is ... / / r532 is ... r533 is ... r403 is [] Thus the - is the and 128 is an , but is out of range and, therefore, the statement is not valid." The assignment statement is NOT VALID. r735 is = following the expr syntax, we eventually find r710 is ... - r701 is r305 is ... r306 is Thus the - is an operator, 128 is an , but is out of range and, therefore, the statement is not valid. Constraining of constants to the range of values is described in 4.0. "Intrinsic data types are parameterized. In this case the set of values is constrained by the value of the parameter ..." and "An example ... is the integer data type. This data type has a processor-dependent set of integer numeric values, each of which is denoted by ..." A program is not standard-conforming if it contains references to integers that are outside the range specified by the processor (1.4). While a standard-conforming processor must detect the use of kind type parameters not supported by the processor, it need not detect the use of integers outside the range of a supported kind. EDIT: None SUBMITTED BY: Dick Weaver HISTORY: 93-277 m127 submitted 94-329r1 m131 response, approved 16-1 95-034r1 m132 X3J3 ballot failed 19-1 95-141 m133 revised response approved u.c. 95-183 m134 X3J3 ballot passed 12-4 -------------------------------------------------------------------------------- NUMBER: 000161 TITLE: Modules and private derived types KEYWORDS: module, private, derived type definition, structure component DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: In compiling a Fortran 90 program, the following issues came up: Question 1:Section 4.4.1 (page 34) states: "The accessibility of a derived type may be declared explicitly by an in its or in an (5.2.3). The accessibility is the default if it is not declared explicitly. If a type definition is private, then the type name, the structure value constructor (4.4.4) for the type, any entity that is of the type, and any procedure that has a dummy argument or function result that is of the type are accessible only within the module containing the definition." Applying this to the following code: MODULE M1 PRIVATE TYPE FRED INTEGER F1,F2 END TYPE FRED TYPE(FRED), PUBLIC, PARAMETER :: Y=FRED(1,2) TYPE(FRED), PUBLIC :: X END it can be seen that entities X and Y are accessible only within module M1. Is specifying the PUBLIC attribute for X and Y an error? Question 2:Now what about this code: MODULE M2 TYPE FRED INTEGER F1,F2 END TYPE FRED END MODULE M3 USE M2 PRIVATE TYPE(FRED), PUBLIC :: X END In module M3, the public type FRED imported from M2 becomes private. Is the declaration of X standard conforming? The text in 4.4.1 is inadequate to cover this scenario. The declaration should be illegal but it depends on what is meant by "module containing the definition" in 4.4.1. The standard appears to describe the M1 case not the M3 case. The problem appears to be that module M2 contains the definition of the public type FRED and the module M3 contains the "definition" of the private type FRED. ANSWER 1: Yes. ANSWER 2: Yes. The declaration of X in the module M3 is standard conforming. Discussion: The answer to question 2 depends on the interpretation of what it means for a module to "contain a definition" of a type. The second paragraph of section 4.4.2 states: "Two entities have the same type if they are declared with respect to the same type definition. The definition may be accessed from a module..." This wording implies that module M3 does not contain a definition of the type FRED; it accesses the definition contained in module M2. Thus, it is the accessibility of FRED in module M2 that is referred to by the cited paragraph in 4.4.1. In section 11.3.2, the last paragraph before the examples singles out the PUBLIC and PRIVATE attributes as different from all other attributes in that they can be respecified in a module that accesses an entity by use association. This paragraph also gives an interpretation to such respecification, stating in part: "If the name appears in a PRIVATE statement in a module, the entity is not a public entity of that module." Note specifically the phrase "of that module." The entity in question is still a public entity (of the module where it was defined). Nothing in any scoping unit other than the one where it was defined can change that. The effect of a PRIVATE statement in a module that accesses the entity by use association is just to prevent the "export" of the entity from that module - not to make the original entity private. The entity can still be accessed by using the original module where it was defined. Only in the original module containing the definition does the PRIVATE attribute have the additional interpretation of actually making the entity private. It cannot actually be a private entity of any other module; note that the sentence quoted from section 11.3.2 avoids using such wording, using instead the more awkward negative statement that it is not a public entity of that module. A similar interpretation applies to the 4th constraint after R424 in section 4.4.1: "If a component of a derived type is of a type declared to be private, either the derived type definition must contain the PRIVATE statement or the derived type must be private." If the type of a component is accessed by use association, then it must have been public in the module that defined it, so this constraint does not apply. The module MODULE M4 USE M5 PRIVATE PUBLIC X END MODULE M4 is always legal if X is a public entity of M5. Suppose that M5 is MODULE M5 USE M6 TYPE JOE TYPE(RALPH) :: J1 END TYPE TYPE(JOE) :: X END MODULE M5 If the constraint in section 4.4.1 were interpreted differently, then module M4 would have to declare at least JOE and RALPH to be public. It might conceivably also need to declare other names to be public; we cannot tell without examining at least module M6 and possibly other modules used in turn. This dependence on the details of the used modules would make an "object-oriented" style of programming difficult. Module M4 does not have any obvious reason for needing to depend on the detailed structure of the type of X. Note that a module can declare an object to be public when the type of the object is not even accessible in the module. For example MODULE M7 USE M5, ONLY :: X PRIVATE PUBLIC X END MODULE M7 Nowhere is there any restriction against this. Considering that module M7 is standard conforming, it would be strange if adding a "USE M5, ONLY: JOE" suddenly made the "PUBLIC X" statement nonconforming. EDIT: None SUBMITTED BY: G. Barber HISTORY: 93-290 m127 submitted 94-322 m131 answered, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0; returned to subgroup for editorial changes 95-086 m132 new version after editorial changes -------------------------------------------------------------------------------- NUMBER: 000164 TITLE: Use of ONLY with multipart definitions KEYWORDS: ONLY, module, derived type DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Sections 11.3.1 and 11.3.2, among others, describe how accessibility of data objects, derived type definitions, etc. can be controlled via the ONLY clause of the USE statement and via the PUBLIC and PRIVATE accessibility attributes/statements. But these sections do not describe what happens when a definition consists of multiple parts and only some of the parts have their accessibility controlled. Examples include, but are not limited, to the following: Example 1: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY END MODULE PROGRAM MAIN USE MOD, ONLY: ARRAY ... END PROGRAM Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? Is the array constructor for ARRAY, for example, accessible to the main program? Example 2: MODULE MOD TYPE INNER INTEGER I END TYPE TYPE OUTER INTEGER K TYPE(INNER) COMP END TYPE END MODULE PROGRAM MAIN USE MOD, ONLY: OUTER ... END MODULE The derived type OUTER in module MOD has a component of derived type INNER. However, when the main program accesses the module, it restricts access to only derived type OUTER. Since OUTER depends on the definition of INNER, is it valid to only allow access to OUTER? If it is not valid, is it only an error if something in the main program actually tries to use OUTER? Can you write a structure constructor for OUTER in the main program? If it is valid, can component I of substructure COMP be referenced? Example 3: MODULE MOD TYPE DEF INTEGER K REAL R END TYPE TYPE(DEF) VAR END MODULE PROGRAM MAIN USE MOD, ONLY: VAR ... END MODULE In this example, only the variable VAR from the module is accessible; its type is not. Is this valid? If it is valid, can only the structure name VAR be referenced or can its components also be referenced? If only the structure name VAR can be referenced, what is the meaning when the structure name is included in a namelist object list for input and/or output? Example 4: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY PRIVATE MAX_SIZE END MODULE PROGRAM MAIN USE MOD ... END PROGRAM Another way to limit access to items in modules is via the PRIVATE attribute/statement. Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? Is the array constructor for ARRAY, for example, accessible to the main program? ANSWER: EDIT(S): SUBMITTED BY: Larry Rolison HISTORY: 94-038 m128 submitted -------------------------------------------------------------------------------- NUMBER: 000167 TITLE: Subscripts and Substrings in Initialization expressions KEYWORDS: expression - initialization, subobject, expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Can an initialization expression include arbitrary expressions for subscript or substring values if that subscript or substring value is not needed to evaluate the initialization expression? Consider the following example SUBROUTINE XX() CHARACTER *10 TEXT(20) INTEGER, PARAMETER:: I = LEN(TEXT(B+I+FNC(R))) INTEGER B, FNC ALLOCATABLE R(:) .... END SUBROUTINE The subscript of 'TEXT' is not relevant to the evaluation of the inquiry 'LEN'. There appears to be no restrictions in the standard against specifying such an arbitrary expression for the subscript. Note that with the definition of 'restricted expression' there is text [79:17-18] that indicates that any subscript, section subscript, substring starting point, or substring ending point must be a restricted expression. It would seem advisable to have an equivalent statement with the definition of an initialization expression. Section 7.1.6.1 indicates that with a subobject of a constant any subscript, must be an initialization expression (77:36-37). This restriction does not apply to this example as 'TEXT' is not a constant, so 'TEXT(B+I+FNC(R))' is not a subobject of a constant. ANSWER: No. The subscripts, section subscripts, substring starting points and substring ending points in an initialization expression must also be initialization expressions. Discussion: The restrictions for the subscripts, section subscripts, substring starting points and substring ending points as specified for subobjects of constants in constant expressions and initialization expressions should also have been applied to variables that are subobjects. Edits are supplied to correct this oversight. The code fragment shown in the question is not standard conforming. EDITS: 1. Section 7.1.6.1, in item (1) of the first list [77:17-18] change: 'constant where each subscript, section subscript, substring starting point, and substring ending point is a constant expression.' to: 'constant,' 2. Section 7.1.6.1. in the last item of the first list [77:29] change: '.' to: ',' 3. Section 7.1.6.1 at the end of the first list, in the style similar to the 'and where ...' at the end of the list in 7.1.6.2: [77:29+] add: 'and where each subscript, section subscript, substring starting point, and substring ending point is a constant expression.' 4. Section 7.1.6.1, in item (1) of the second list [77:36-37] change: 'constant where each subscript, section subscript, substring starting point, and substring ending point is an initialization expression,' to: 'constant,' 2. Section 7.1.6.1. in the last item of the second list [78:11] change: '.' to: ',' 3. Section 7.1.6.1 at the end of the second list, in the style similar to the 'and where ...' at the end of the list in 7.1.6.2: [78:11+] add: 'and where each subscript, section subscript, substring starting point, and substring ending point is an initialization expression.' SUBMITTED BY: Janice C. Shepherd HISTORY: 93-286 m127 submitted 94-333 m131 proposed response, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0 -------------------------------------------------------------------------------- NUMBER: 000168 TITLE: USE ONLY and NAMELIST KEYWORDS: use association, i/o namelist, ONLY, host association DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: If a scoping unit accesses a namelist group name by use association must all the namelist group objects also be accessible in the scoping unit? Consider the following example MODULE M1 NAMELIST /N/ I,J,K END MODULE USE M1, ONLY: N, I ... WRITE(10,N) The section in the standard on the NAMELIST statement (5.4) indicates that a namelist group name must not be PUBLIC if any of its namelist group items have the PRIVATE attribute. But in this example the namelist group name and each of its namelist group items have the PUBLIC attribute. Within the program only the namelist group name and one of its three namelist items are accessible. ANSWER: No. A namelist group name accessed by host or use association may be referenced even if not all the namelist group items are accessible by host or use association. Discussion: There is no restriction in the standard on the use of a namelist group name that is accessed by host or use association even if some or all of its namelist group objects are not accessible in the scoping unit. The code fragment in the question is standard conforming as is the following code fragment: PROGRAM HOST NAMELIST /N/ I,J,K I = 1 J = 2 K = 3 CALL INNER() CONTAINS SUBROUTINE INNER() INTEGER J ! J from the host is not accessible J = 10 ... WRITE(10, N) ... The 2nd constraint of section 5.4 is disallowing a namelist group name from being accessible outside a module if any of its namelist group objects have restrictions on their accessibility outside the module. If a module has been written such that some variables are private or have private components, the private variables or private components should not be accessible outside the module indirectly through a namelist group name. The 'ONLY' keyword on a USE statement is for limiting access to mainly avoid name conflicts in the scoping unit. It is not intended to restrict all means of access to a publicly accessible entity. In both examples, the namelist items that appeared in the NAMELIST statements, are the data objects that are being output by the WRITE statements. EDIT(S): None SUBMITTED BY: Janice C. Shepherd HISTORY: 93-287 m127 submitted 94-330r1 m131 proposed response, approved u.c. 95-034r1 m132 X3J3 ballot approved 20-0, with edit -------------------------------------------------------------------------------- NUMBER: 000171 TITLE: Equivalence of DBLE(A) and REAL(A,KIND(0.0D0)) Intrinsics KEYWORDS: DBLE intrinsic, REAL intrinsic DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Given A of type integer, real, or complex, must the expression DBLE (A) == REAL (A, KIND(0.0D0)) always evaluate to .TRUE. for each type and kind? The text that describes the 'Result Value' of DBLE in section 13.13.27 would be easier to understand if it just stated that the result has the value REAL (A, KIND (0.0D0)). ANSWER: Yes. This result, however, is not specified in the 'Result Value' text of the two functions. Where DBLE specifies 'as much precision ... as a double precision real datum can contain.', REAL specifies a 'processor-dependent approximation'. An edit is provided. EDIT: In 13.13.27 DBLE, replace the text of the 'Result Value' section with: [205:7-11] "The result has the value REAL (A, KIND (0.0D0) )." SUBMITTED BY: Dick Weaver HISTORY: 94-018 m128 submitted 94-331 m131 Included section reference in question, approved u.c. 95-034r1 m132 X3J3 ballot approved 20-0 -------------------------------------------------------------------------------- NUMBER: 000173 TITLE: Definition of elemental intrinsic subroutine KEYWORDS: intrinsic, elemental subroutine, MVBITS DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 Section 13.2.2 defines an elemental subroutine as one that is specified for scalar arguments but may be applied to array arguments. MVBITS, 13.13.74 for example, is identified as an elemental subroutine. Section 13.2.2 asserts that, in the case of array arguments, the results are the same as would be obtained if the subroutine were applied separately to corresponding elements of each array. This assertion is true only if the input and output arguments do not overlap but there does not appear to be such a requirement. Question 1: For elemental intrinsic subroutines, is a requirement or constraint along the lines of "input and output arguments must not be associated" missing? Question 2: Alternatively, should the text about "same results" be deleted and semantics added to these subroutines similar to those for assignment? ANSWER 1: Yes. A restriction similar to the suggested restriction is missing. ANSWER 2: No. The committee decided this imposed too great a burden on Fortran processors for the functionality provided. Discussion: The text in 13.13.74 which describes the "TO" argument specifically allows FROM and TO to be the same variable (which includes s). The standard should have prohibited the FROM and TO arguments from being associated in any other way, including partial overlaps. The TO argument should also be prohibited from being associated with any other argument to MVBITS. The other intrinsic subroutines should have had similar restrictions. EDIT: Add the following sentences to the end of section 13.2.2 [183:35]: "In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM dummy arguments may be the same variable. Apart from this, the actual arguments in a reference to an intrinsic subroutine must satisfy the restrictions of 12.5.2.9. SUBMITTED BY: Dick Weaver HISTORY: 94-121 m129 submitted 95-023r1 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot failed 10-8 95-144 m133 revised response, approved u.c. 95-183 m134 X3J3 ballot passed 15-2 -------------------------------------------------------------------------------- NUMBER: 000175 TITLE: What is a "constant specification expression"? KEYWORDS: constant specification expression, expression - constant, specification expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: The term "constant specification expression" is used in several places (in two constraints following R429, for example), but nowhere defined. What is the definition of "constant specification expression"? ANSWER:A constant specification expression is a specification expression that is also a constant expression. An edit is supplied to define this term. The edit is needed to make it clear that it is not sufficient for the value of the specification expression to be fixed. For example, if IC is a named constant with value 0 and I is a dummy argument, IC*I always has the value 0, but this is not a constant specification expression. EDIT: In section 7.1.6.2, add to the paragraph ahead of R734 [79:19] "A is a specification expression that is also a constant expression." SUBMITTED BY: Dick Weaver HISTORY: 94-137 m129 submitted 95-186 m134 response proposed, approved u.c. 95-256 m135 X3J3 ballot, approved 15-1 -------------------------------------------------------------------------------- NUMBER: 000176 TITLE: Definition of RANDOM_SEED KEYWORDS: RANDOM_SEED intrinsic DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: The definition in 13.13.84, RANDOM_SEED, for the optional argument GET is: must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. It is set by the processor to the current value of the seed. There is similar text for the PUT argument. For both cases -- "set" is used in a manner that appears to specify assignment. For similar uses of "set" see DATE_AND_TIME, IBSET, and SET_EXPONENT. -- "current value" is not the same thing as "physical representation". Setting, or assignment, of a value and necessary conversions, are described in section 7.5. "physical representation", however, was more likely intended for RANDOM_SEED. -- The shape of the seed is processor dependent and the specification for both GET and PUT results in different semantics depending on whether the processor's seed is an array of default integers, an array of some other numeric type, or a scalar. Further, the descriptions of PUT "set the seed value" and GET "set . . . to the current value of the seed" would appear to specify that: -- the processor must accept whatever is specified for a seed value when some values, 0 for example, are often not suitable -- PUT and GET can be used for global communication; assigning a value with PUT and later retrieving that same value with GET. 1. Is the following what was intended for GET? must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. Denoting this array by "a" and the current value of the seed by "s", TRANSFER (SOURCE=s, MOLD=a) is assigned to "a". TRANSFER hides both type and shape, assigning not the current value of the seed but the physical representation of that value independent of shape. Thus the seed can be of any type and any shape. Alternately must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. It is assigned the physical representation of the seed value in a processor dependent manner. 2. PUT semantics are more complicated in that the argument specified for PUT may not always be suitable as a seed. Thus while the assignment semantics currently specified may not have been intended, neither is it appropriate to specify TRANSFER semantics. Are PUT semantics processor dependent? This would allow processor seeds of any type and shape. 3. Given a value specified for PUT, can processors alter that value for use as a seed? ANSWER: 1. Yes, for GET "TRANSFER" semantics were intended, however "processor dependent" is both more general and parallels the PUT edit. 2. Yes, specifying PUT semantics as processor-dependent is correct. 3. Yes, the value supplied by PUT may be altered in constructing a seed. Edits provided in defect item 000148 describe the operation of RANDOM_SEED and RANDOM_NUMBER. Edits to the description of RANDOM_SEED arguments PUT and GET are provided here. EDIT: 1. In 13.13.84, RANDOM_SEED, PUT argument, replace the last sentence (beginning "It is used by the processor . . .") with [228:9]: "It is used in a processor-dependent manner to compute the seed value accessed by the pseudorandom number generator." 2. In 13.13.84, RANDOM_SEED, GET argument, replace the last sentence (beginning "It is set by the processor . . .") with [228:12]: "It is set to the current value of the seed in a processor dependent manner." SUBMITTED BY: Dick Weaver HISTORY: 94-142r1 m129 submitted, approved u.c. 94-221 m130 X3J3 ballot, failed 21-2 94-324r1 m131 revised response, approved 16-1 95-034r1 m132 X3J3 ballot, approved 19-1 HOLD for defect item 000148 95-155 m133 revised response, approved 12-1 95-183 m134 X3J3 ballot, failed 16-2 -------------------------------------------------------------------------------- NUMBER: 000179 TITLE: DO variable with POINTER attribute KEYWORDS: DO variable, POINTER attribute DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: The first constraint following rule R822 states: "Constraint: The must be a named scalar variable of type integer, default real, or double precision real." The definition of loop initiation (8.1.4.4.1) states: "(2) The DO variable becomes defined with the value of the initial parameter 1." The definition of the execution cycle of a DO loop (8.1.4.4.2) states: "(3) ... The DO variable, if any, is incremented by the value of the incrementation parameter 3." Consider the following program: INTEGER, POINTER :: PTR INTEGER, TARGET :: LCV PTR => LCV DO PTR = 1, 3 PRINT *, LCV END DO END Note that the DO variable has the POINTER attribute. The POINTER attribute does not seem to be prohibited for the DO variable, but when the DO variable has the POINTER attribute, it is unclear as to whether the DO variable is the pointer or the target of the pointer. That is, it is unclear as to whether the pointer or the target is to be "defined" (8.1.4.4.1) or incremented (8.1.4.4.2). Also consider the following modification of the above program: INTEGER, POINTER :: PTR INTEGER, TARGET :: LCV1, LCV2 LCV1 = 1 LCV2 = 4 PTR => LCV1 DO PTR = 1, 3 IF (...) PTR => LCV2 ! An alternate EXIT form? END DO END The standard does not seem to address what happens when the DO variable is switched to a different variable while the loop is active. Did the standard mean to allow a DO variable to have the POINTER attribute? ANSWER: No. This oversight has been remedied by an edit. Discussion: The description of the iterative form of the DO loop was essentially carried forward from the previous standard. It was an oversight to not prohibit the DO variable from having the POINTER attribute. Prohibiting the POINTER attribute prevents the confusion that can arise as demonstrated by the example programs given above. EDITS: 1. Section 8.1.4.1.1 in the first constraint following rule R822 [100:38] insert "nonpointer" before "named". 2. Section 9.4.2 in the second constraint following rule R918, replace "scalar" with "nonpointer named scalar variable". SUBMITTED BY: Larry Rolison HISTORY: 94-226r1 m130 submitted, approved 10-1 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot, failed see Cohen's comments 95-246 m134 revised edits, approved u.c. 95-256 m135 X3J3 ballot, failed 10-6