VHDL Issue Number: 2029 Language_Version: VHDL-93 Classification: LRM Terminology, Grammar and Typographical Errors Summary: Non-relevant words and paragraph. Relevant_LRM_Sections: 4.3.1.1 Constant Declaration 4.3.1.2 Signal Declaration 4.3.2 Interfaces Declaration 3.4 File Types Proposed_Resolution: Remove the phrases and paragraph. Related_Issues: Key_Words_and_Phrases: file type, alias Authors_Name: Gingold Tristan Authors_Phone_Number: 0 Authors_Fax_Number: 0 Authors_Email_Address: tgingold@free.fr Authors_Affiliation: none Authors_Address1: - Authors_Address2: - Authors_Address3: - Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 12 July 2003 Date Analyzed: 10 August 2004 Author of Analysis: Ajayharsh Varikat Revision Number: 03 Date Last Revised: 15 November 2005 Description of Problem ---------------------- At several places, the LRM states "It is an error if a [...] is of a file type or, an access type, or a composite type which has a subelement that is a file type or an access type." This suggests that a composite type can have a subelement of a file type. But this is explicitly invalid, per clause 3.2, "a composite type may only contain elements that are of scalar, composite, or access types; elements of file types are not allowed in a composite type." Therefore, the precision is not relevant and should be removed (or moved into a note). For a similar reason, this paragraph of clause 4.3.3.2 (Nonobject aliases) can be removed: d) Alternatively, if the name denotes a physical type [...] Indeed, physical types are always anonymous. This is due to clause 3.1.3 (Physical types): A physical type definition defines both a type and a subtype of that type. The type is an anonymous type, [...] As a consequence, the use of a nonobject alias is certainly more limited than expected (export feature described in LCS-0008). Proposed Resolution ------------------- Remove the phrases and paragraph. VASG-ISAC Analysis & Rationale ------------------------------ The second issue in this IR about the name of a physical type is covered by IR 2038. We analyze the first issue here. Section 3.2 of the LRM specifies that a composite type may not have a subelement that is of a file type or a protected type. There are several other sections (3.3, 3.5.1, 4.3.1.1, 4.3.1.2, 4.4) where the LRM forbids subelements of file types and protected types in specific contexts. This is redundant, and could potentially cause confusion about whether subelements of these types are allowed in other contexts. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change is needed, since the net effect is to remove correct but confusing language. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Make the following changes in the LRM. Section 3.3 The last sentence of the last paragraph on page 45 of the LRM should be changed from "The designated type must not be a file type or a protected type; moreover, it must not have a subelement that is a file type or a protected type." to the following: "The designated type must not be a file type or a protected type." Section 3.5.1 The last two sentences of the second paragraph on page 51 of the LRM should be changed from "Such formal parameters must not be of an access type or a file type; moreover, they must not have a subelement that is an access type or a file type. Additionally, in the case of a function subprogram, the return type of the function must not be of an access type of a file type; moreover, it must not have a subelement that is an access type or a file type." to the following: "Such formal parameters must not be of an access type or a file type; moreover, they must not have a subelement that is of an access type. Additionally, in the case of a function subprogram, the return type of the function must not be of an access type or a file type; moreover, it must not have a subelement that is of an access type." Section 4.3.1.1: The last sentence in this section before the note should be changed from "It is an error if a constant declaration declares a constant that is of a file type, an access type, or a composite type that has a subelement that is a file type, an access type, or a protected type." to the following: "It is an error if a constant declaration declares a constant that is of a file type, an access type, or a composite type that has a subelement that is of an access type." Section 4.3.1.2 The first sentence of the sixth paragraph in this section should be changed from "It is an error if a signal declaration declares a signal that is of a file type, a protected type, or a composite type having a subelement that is a file type, an access type, or a protected type." to the following: "It is an error if a signal declaration declares a signal that is of a file type, a protected type, or a composite type having a subelement that is of an access type." Section 4.3.2 The last sentence in the first paragraph on page 64 of the LRM should be changed from "Moreover, the subtype indication must not denote a composite type with a subelement that is a file type, an access type, or a protected type." to the following: "Moreover, the subtype indication must not denote a composite type with a subelement that is of an access type." Section 4.4 The first sentence in the first paragraph on page 72 should be changed from "It is an error if the type mark denotes an access type, a file type, a protected type, or a composite type with a subelement that is an access type, a file type, or a protected type." to the following: "It is an error if the type mark denotes an access type, a file type, a protected type, or a composite type with a subelement that is of an access type."