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 autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!uupsi!grebyn!eberard From: eberard@grebyn.com (Ed Berard) Newsgroups: comp.lang.ada Subject: Generics and Ada Compiler Validation Keywords: generics, ACVC coverage Message-ID: <20121@grebyn.com> Date: 8 Jun 90 17:40:16 GMT Organization: Grebyn Timesharing, Vienna, VA List-Id: The Ada Compiler Validation Capability (ACVC) contains a suite of test programs used to determine the conformance of potential Ada compilers with the syntax and semantics described in the Ada Language Reference Manual (ALRM, ANSI/MIL STD 1815A). Within the test suite, there are six major categories of test programs: - Class A: These tests are supposed to compile and execute with no problems. - Class B: These tests are expected to fail compilation - Class C: These tests are supposed to compile and execute with no errors, but also do run-time checking - Class D: These tests do capacity checking - Class E: These tests check implementation-dependent features and ambiguities - Class L: These tests are supposed to fail at link time. The general understanding is that ACVC tests are _not_ intended to be used as benchmarks, nor are they intended to test the limits of an Ada compiler. (There are a number of Ada Compiler Evaluation Capability (ACEC) tests which claim to address these issues.) Simply because a given Ada compiler successfully passes the latest version of the ACVC, does not mean that the compiler contains no errors. Nor does passing the ACVC mean _perfect_ compliance with the syntax and semantics described in the ALRM. However, efforts are constantly underway to improve the testing capabilities of the ACVC. I am soliciting information from Ada compiler implementors and users regarding that portion of the ACVC which tests generics -- a language feature covered primarily in Chapter 12 of the ALRM. Specifically, I am looking for ways to _improve_ the ACVC's coverage of generics. For example, I would be interested in hearing about the following situations: - You are using a validated Ada compiler (validated under the latest version of the ACVC) and you find that _valid_ (according to the ALRM) Ada source code does _not_ compile. Equally important, the specific source code which does not compile involves the syntax and semantics of generics. - You are using a validated Ada compiler (validated under the latest version of the ACVC) and you find that _invalid_ (according to the ALRM) Ada source code _does_ compile. Equally important, the specific _invalid_ source code which does compile involves the (potentially bogus) syntax and semantics of generics. - You are using a validated Ada compiler (validated under the latest version of the ACVC) and you find that _valid_ (according to the ALRM) Ada source code compiles, but the generated object code does _not_ behave correctly. Specifically, the compiler generates code which does not conform to the semantics described in the ALRM. Equally important, the source code must specifically contain generics and, to the best of your determination, the (bogus) object code must be incorrectly implementing the semantics of those generics. - You are using a validated Ada compiler (validated under the latest version of the ACVC) and you find that, although the compiler compiles valid Ada source code, and the generated object code conforms exactly to the semantics described in the ALRM, there is some "unreasonable" constraint on the behavior (or some other characteristic) of the generated object code. Equally important, the source code must contain generics, and, to the best of your determination, the "unreasonable" constraint must be specifically tied to the use of these generics. - You have just noticed (or known about for some time) a "gaping hole" in the way the ACVC tests generics. You may be a (possibly frustrated) user who has been doing "write arounds" to compensate for this problem. You may even be a compiler vendor who has not yet had the time to bring this to the attention of the Ada Validation Office (AVO). For each report, I would find the following information most helpful: 1. A general description of the problem/deficiency 2. The specific Ada compiler(s) (vendor, version number, and platform (hardware and software)) where you have found the problem/deficiency. 3. The smallest (measured in lines of code) possible piece of Ada source code which will reproduce the problem/deficiency. 4. Any additional information, comments, or suggestions you may wish to make. This information will be included in a report which will be placed in the public domain. If you do not wish me to reveal some specific information contained in your report, please indicate this. This information will also be used to enhance the generics testing in the next version of the ACVC, so please reply promptly. Thank you for any time and consideration. -- Ed Berard Berard Software Engineering, Inc. 18620 Mateney Road Germantown, Maryland 20874 Phone: (301) 353-9652 FAX: (301) 353-9272