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 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!caip!princeton!siemens!gypsy!rosen From: rosen@gypsy.UUCP Newsgroups: net.lang.ada Subject: Ada Compiler Demolition Derby Message-ID: <38000032@gypsy.UUCP> Date: Wed, 16-Jul-86 19:01:00 EDT Article-I.D.: gypsy.38000032 Posted: Wed Jul 16 19:01:00 1986 Date-Received: Thu, 17-Jul-86 05:56:29 EDT Nf-ID: #N:gypsy:38000032:000:7907 Nf-From: gypsy!rosen Jul 16 19:01:00 1986 List-Id: If you are currently in the process of trying to implement an Ada compiler (god help you!) or are wondering just how good your compiler is, you may be interested in the following programs. A co-worker and myself happended to stumble across a bunch of Ada programs that caused our Ada compilers to do unexpected things. You may be interested in trying the programs out with your compiler to see what happends. I am purposely leaving out the compilers that I used (I used more than one) so that it won't appear as if I am picking on any one compiler. If you run the tests and send me the results based on the classifications that I list below, I will post to the net in the near future. These tests should probably end up in the ACVC test, but that isn't my concern here. You should tell me the version of Ada compiler that you used. Here are the classifications: ****************************************************************************** Compilation classes of test programs: CLASS MEANING ----- -------------------------------------------------------------- A Should definitely compile and did compile. B Should definitely compile and did not compile. C Should definitely not compile and did compile. D Should definitely not compile and did not compile. E Should defintely not compile and compiler printed internal diagnostic. F Should defintely compile and compiler printed internal diagnostic. G Compiler dies without giving any useful diagnostic. ------------------------------------------------------------------------------ ****************************************************************************** Here is what my compilers did: TEST # CLASS compiler #1 compiler #2 ------ ----------------------------------------- 01 (rename1.a) E D 02 (rename2.a) A A 03 (separate1.a) B B 04 (separate2.a) B B 05 (type1.a) C D 06 (type2.a) E D 07 (use.a) B B ****************************************************************************** What is real surprising is that these two validated compilers both failed to compile the same program in a couple of cases where it should have (case 03, 04, and 07 for instance). In the code I tried to give an explaination of why I think the code should compile. If you tend to think that I am wrong about any of my assertions (I claim the program should compile, but you disagree), please let me know what your point of view is. I tried to check these pretty carefully and I think I am right in all cases, but Ada is so complicated I admit I could easily have overlooked something. Here are the programs in Unix shar format. If you have VMS and want me to send you the programs in non-shar format send me mail. Actually I have come to the conclusion that current Ada compilers have reached their theoretically limit of purity and it is not possible to ever make a compiler any more correct :-) . -----CUT HERE------ #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # rename1.a # rename2.a # separate1.a # separate2.a # type1.a # type2.a # use.a # This archive created: Wed Jul 16 18:40:55 1986 export PATH; PATH=/bin:$PATH if test -f 'rename1.a' then echo shar: will not over-write existing file "'rename1.a'" else echo Extracting rename1.a cat << \SHAR_EOF > 'rename1.a' -------- -- 01 -- -------- -- -- Should not work. Below program is not legal. Cannot reference an -- item during its own declaration. -- package SOME_PACKAGE is procedure PROC renames SOME_PACKAGE.PROC; end SOME_PACKAGE; SHAR_EOF fi # end of overwriting check if test -f 'rename2.a' then echo shar: will not over-write existing file "'rename2.a'" else echo Extracting rename2.a cat << \SHAR_EOF > 'rename2.a' -------- -- 02 -- -------- -- -- This should work. It's legal Ada. -- package A is package B renames A; package C renames B; package D renames C; package E renames D; end A; with A; package X is use A.B.C.D.E.B.C.D.E.B.C.D.E.B.C.D.E.B.C.D.E; Z: INTEGER; end X; SHAR_EOF fi # end of overwriting check if test -f 'separate1.a' then echo shar: will not over-write existing file "'separate1.a'" else echo Extracting separate1.a cat << \SHAR_EOF > 'separate1.a' -------- -- 03 -- -------- -- -- Should work according to semantics of rename (LRM 8.5(3)), but doesn't -- package A is package B renames A; procedure C; end A; package body A is procedure C is separate; end A; separate (A.B) procedure C is begin null; end C; SHAR_EOF fi # end of overwriting check if test -f 'separate2.a' then echo shar: will not over-write existing file "'separate2.a'" else echo Extracting separate2.a cat << \SHAR_EOF > 'separate2.a' -------- -- 04 -- -------- -- -- Should work according to semantics of rename (LRM 8.5(3)), but doesn't -- package A is procedure B; procedure C renames B; end A; package body A is procedure B is separate; end A; separate (A) procedure B is procedure X is separate; begin null; end B; separate (A.C) procedure X is begin null; end X; SHAR_EOF fi # end of overwriting check if test -f 'type1.a' then echo shar: will not over-write existing file "'type1.a'" else echo Extracting type1.a cat << \SHAR_EOF > 'type1.a' -------- -- 05 -- -------- -- -- Should not work, there is a mistaken identifier in case statement -- procedure PROC is type FRUIT is (APPLE, PEAR, PEACH, PLUM, GRAPEFRUIT, ORANGE); X: FRUIT := GRAPEFRUIT; begin case FRUIT is -- Uh-oh, wrong identifier here, meant X when OTHERS => X := FRUIT'FIRST; end case; end PROC; SHAR_EOF fi # end of overwriting check if test -f 'type2.a' then echo shar: will not over-write existing file "'type2.a'" else echo Extracting type2.a cat << \SHAR_EOF > 'type2.a' -------- -- 06 -- -------- -- -- Should not work, there is a mistaken identifier in case statement -- procedure PROC is type FRUIT is (APPLE, PEAR, PEACH, PLUM, GRAPEFRUIT, ORANGE); X: FRUIT := GRAPEFRUIT; begin case FRUIT is -- Uh-oh, wrong identifier here, meant X when APPLE => null; when OTHERS => X := FRUIT'FIRST; end case; end PROC; SHAR_EOF fi # end of overwriting check if test -f 'use.a' then echo shar: will not over-write existing file "'use.a'" else echo Extracting use.a cat << \SHAR_EOF > 'use.a' -------- -- 07 -- -------- -- -- Should work. Compiler complains saying a visible declaration for -- FRUIT is hidden by the use of the 'use' clause in the context clause -- for the body of package B. -- -- The 'use' clause in the body of package B should have no effect since -- there is already a 'use' for package A in the spec of package B that will -- allow declarations in A to be visible in the body of B. -- -- Proof: -- -- 8.1(2) - Declaritive region of package spec includes its own body -- 8.4(3) - Use of 'use' clause covers entire declarative region -- 8.4(9) - Repeated 'use' clauses have no effect. -- -- Therefore, there is no visible declaration to be hidden -- package A is type FRUIT is (apple, banana, cherry); end A; with A; package B is use A; SOME_FRUIT: FRUIT; end B; with A; use A; -- Take out this 'use' clause to make units compile -- Whether it is there or not should have no effect package body B is OTHER_FRUIT: FRUIT; end B; SHAR_EOF fi # end of overwriting check # End of shell archive exit 0 ****************************************************************************** ---------------- | Steve Rosen | Siemens Research and Technology Laboratories | Princeton, NJ USENET: adrvax\ ihnp4 | princeton |-->!siemens!gypsy!rosen topaz | vrdxhq/ ARPA: siemens!gypsy!rosen@topaz.rutgers.edu