From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,PLING_QUERY,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbosgd!gatech!dana From: dana@gatech.CSNET (Dana Eckart) Newsgroups: net.lang.ada Subject: Ada compiler bug?! Message-ID: <3968@gatech.CSNET> Date: Tue, 24-Jun-86 12:20:12 EDT Article-I.D.: gatech.3968 Posted: Tue Jun 24 12:20:12 1986 Date-Received: Wed, 25-Jun-86 05:28:53 EDT Reply-To: dana@gatech.UUCP (Dana Eckart) Organization: School of Information and Computer Science, Georgia Tech, Atlanta List-Id: Attention! There is a possible "bug" which may be in a great many Ada compilers. An error may be flagged (at compiler time) when the instantiation of a generic package which tries to match a formal private parameter to an actual parameter that is a discriminated record is attempted. The reason that I feel this IS supposed to be supported by the language is the following from the Ada LRM (12.3.2 paragraphs 1 - 4): A generic formal private type is matched by any type or subtype (the actual subtype) that satisfies the following conditions: * If the formal type is not limited, the actual type must not be a limited type. (If, on the other hand, the formal type is limited, no such condition is imposed on the corresponding actual type, which can be limited or not limited.) * If the formal type has a discriminant part, the actual type must be a type with the same number of discriminants; the type of a discriminant that appears at a given position in the discriminant part of the actual type must be the same as the position in the discriminant part of the formal type; and the actual subtype must be unconstrained. (If, on the other hand, the formal type has no discriminants, the actual type is allowed to have discriminants.) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Last sentence seems to indicate that the instantiation should be allowed. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Furthermore, consider any occurrence of the name of the formal type at a place where this name is used as an unconstrained subtype indication. The actual subtype must not be an unconstrained array type or an unconstrained type with discriminants, if any of these occurrences is at a place where either a constraint or default discriminants would be required for an array type or for a type with discriminants (see 3.6.1 and 3.7.2). <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Last sentence seems to indicate that the instantiation should be allowed. However, notice that this sentence is an implication with the conditional part last. I have asked someone else's opinion of this and we feel that implementors have probably over generalized this last statement, thus causing the "bug" (or is it a feature? :-). <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The same restriction applies to occurrences of the name of a subtype of the formal type, and to occurrences of the name of any type of subtype derived, directly or indirectly, from the formal type. The following is an easy example to test whether or not your compiler suffers from this problem. dotted line ------------------------------------------------------------------------- package PERSON is type GENDER is (MALE, FEMALE); type PERSON (SEX : GENDER := MALE) is record null; end record; end PERSON; generic type ELEMENT_TYPE is private; package LIST is type LIST is private; private type LIST_NODE; type LIST is access LIST_NODE; end LIST; package body LIST is type LIST_NODE is record ITEM : ELEMENT_TYPE; NEXT : LIST; end record; end LIST; with PERSON, LIST; use PERSON; procedure TEST is -- -- The problem should manifest itself by flagging an error -- for the following statement. -- package COMMUNITY is new LIST (PERSON.PERSON); CITY : COMMUNITY.LIST; begin null; end TEST; pragma MAIN; dotted line ------------------------------------------------------------------------- I ask everyone to please try this example on their own compilers and to send me mail concerning the results. I suppose the only information I really need is: (1) The compiler that was used (don't forget the version) (2) Did it compile without complaint? (yes/no) * If it did complain and it doesn't seem related to the issues pointed out here, please include the errors flagged. (3) If it compiled, did it generate any run-time errors? (yes/no) * If so, which ones, and where were they raised. (4) If you know of a test in the validation suite that is similar (or that tests for the same type of thing) please let me know about it and if possible send me the code (assuming it is small) and the first version of the suite which used it. (5) Finally, if you happen to think that I have misinterpreted the LRM please tell me how I have misinterpreted it and why you think so. When I feel that I have gotten most, if not all, of the results I will try to summarize and report back to the net (hopefully within 2 weeks time). I wish to thank everyone in advance for their help and cooperation. If my understanding of the matter is correct, I think that this is a very serious problem. Not only is it an excellent illustration of the difficulty of adequate testing (e.g. the validation suite), but it also points out the problem of reading and interpreting English statements describing the semantics of a programming language. j dana eckart CSNet: dana @ GATech ARPA: dana%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!dana -- j dana eckart CSNet: dana @ GATech ARPA: dana%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!dana