REQUIRED OR PERMISSABLE TEST MODIFICATIONS TO ACVC 2.1, 98-09-29 ---------------------------------------------------------------- Below are the prescriptions for Test Modifications to 75 ACVC 2.1 test programs and 2 foundation files. This list supercedes the 98-08-04 list, adding 1 test program and editorilally revising three modifications. Some of these modifcations are necessary for all validations, while others may not be necessary but are permissable. In the interest of preserving as much of flawed ACVC test programs as practical, the AVO is directing that certain test programs that contain incorrect checks be modified for use in validation. In general, these modifications affect code that should have been impassable previously, remove code (by commenting it out), or allow a conforming execution path while preserving an incorrect one (so as not to penalize imple- mentation to the ACVC). NEW TEST PROGRAMS & FOUNDATION FILES: ------------------------------------ CE3115A: OUTPUT TO EXTERNAL FILE MAY BE BUFFERED OTHER CHANGES: ------------- C9A007A: ABSENCE OF PRIORITIES RESULTS IN A RACE CONDITION [expanded modification to specify context clause "with IMPDEF;" CXB5004: FORTRAN CODE IS ILLEGAL IN TWO PLACES [corrected modification to say 'INTARR' vice 'INVARR'] CXD4008: WRONG QUEUING POLICY; MULTIPROCESSORS MAY FAIL P.O. & TASK CHECKS [corrected '379, append Checker.ES' to '... Checker.E5'] The entries below are listed by test names in lexicographical order within blocks for the Core Sections and each Annex. Line numbers are given relative to the start of a test file; if a test program comprises more than one file, then the particular file will be indicated by "fn", where "n" is the test-program name's file-designator numeral. E.g., in the test modification given for CXB5004, "f0-79, ..." denotes the first of the test program's files which is names "cxb50040". ::::::::::::::: CORE SECTIONS ::::::::::::::::::::::::::::::::::::::::::::::::: B392002: PRIMITIVE FUNCTION IN PRIV.PART VIOLATES 3.9.3(10) The AVO directs that this test program may be processed with the following grading modification for validation under ACVC 2.1: accept compiler error diagnostics for the (illegal) function declaration at line 186 The function Primitive_Of_Both_Func2, declared at line 186, violates the second sentence of ARM 3.9.3(10) as it is a primitive operation, declared in the private part, of a tagged type that is declared in the visible part, and the function doesn't override anything. This grading modification encourages this unintended illegality to be detected. B393006: DECLARATION OF FUNC @102/3 VIOLATES 3.9.3(10) The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: comment out lines 102, 103, & 112..119 (function decl, pkg body) This code modification will remove an unintended illegality from the test program, while retaining all intended illegalities (the check that is lost is that compilers don't wrongly treat Func as overriding in cases where it isn't--however, in this case, it can't be legally declared for the particular checks). The declaration of function B393006_1.Func (@102/3) violates ARM 3.9.3(10), as it is a primitive function with a controlling result that overrides nothing. With the removal of this function (to comments), the package body becomes unneeded/illegal, and thus must also be commented out. B490001: LINES 295,298,324 ARE INDEED IN "--ERROR", BUT FOR OTHER REASONS The AVO confirms that lines 295, 298, & 324 are illegal (and so marked) for reasons other than what the associated comments in the test program indicate. Consequently, compiler diagnostic messages will likely identify an error that is not expected, given the comments (although such diagnostic output need not have any particular form or content). In the first two cases, the expected type is My_String but the value is of type String; in the last case the "/" operator cannot resolve, as there is none that returns My_Int with an Integer parameter. B610001: PROCEDURE CALLS @221,223,225,228 ARE AMBIGUOUS The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: comment out lines 221, 223, 225, & 228 These lines are ambiguous, by ARM 3.10.2(2) and 8.6(27). B83E01C: ERRORS @172, 177 MAY BE REGARDED AS "OPTIONAL" B83E01D: ERRORS @302, 307 MAY BE REGARDED AS "OPTIONAL" B83E01E: ERRORS @F3-56/-61 MAY BE REGARDED AS "OPTIONAL" The AVO directs that these test programs may be processed with the following grading modification for validation under ACVC 2.1: the intended illegalities for B83E01C at lines 172 & 177 (which are marked with "ERROR") for B83E01D at lines 302 & 307 (which are marked with "ERROR") for B83E01E, file 3, at lines 56 & 61 (which are all marked with "ERROR") may be regarded instead as "optional error"s--i.e., they need not have corresponding diagnostic output from the compiler Each of these cases is the declaration of a generic subprogram body. The only other modification that would address a compiler's failure to detect these lines as errors would be to split the tests with the generic subprogram declarations removed; but this would simply duplicate the cases of the non-generic subprogram bodies, which are checked elsewhere in these test programs. BA21003: COMPILATION WITH ERRORS MAY AFFECT LATER ERROR DETECTION The AVO directs that this test program may be processed with the following processing modification for validation under ACVC 2.1: split the test file BA210030 at line 163, removing the subunit body of package Bad_Subunit from this otherwise error-free compilation; process the subunit as a separate compilation. The Ada 95 standard 10.1(4) allows an implementation "to impose implementation-defined restrictions on compilations that contain multiple compilation_units", such as requiring all such units to be error free. Therefore, this test program might need to be given the above processing modification. BC3503A: ADA95 REQUIRES ACCESS *TYPES*' DESIGNATED SUBTYPES TO STATICLY MATCH The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: comment out lines 100, 109, & 118 (these lines are LEGAL in Ada 95) Each of the package instantiations PS3, PR3, & PP3 is legal in Ada 95, as the requirement for matching in Ada 95 is for the formal and actual access TYPES' (not the actual SUBtype's) designated subtypes. BC3503C: ADA95 REQUIRES ACCESS *TYPES*' DESIGNATED SUBTYPES TO STATICLY MATCH The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: comment out line 63 (this line is LEGAL in Ada 95) The package instantiation PU3 is legal in Ada 95 (see BC3503A's entry). BC51C02: DECLARATION OF FUNC @194 VIOLATES 3.9.3(10) The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: comment out line 194 This code modification will remove an unintended illegality from the test program, while retaining all intended illegalities (the check that is lost is that compilers don't wrongly treat Func as overriding in cases where it isn't--however, in this case, it can't be legally declared for the particular check). The declaration of function PriExt_Overrides_Explicit.Func (@102/3) violates ARM 3.9.3(10), as it is a primitive function with a controlling result that overrides nothing. With the removal of this function (to comments), the package body becomes unneeded/illegal, and thus must also be commented out. BDE0001: BOTH IMPLICIT & EXPLICIT FUNCTIONS @154 VIOLATE 3.9.3(10) The AVO directs that this test program may be processed with the following grading modification for validation under ACVC 2.1: accept compiler error diagnostics for lines 153 & 154 The implicit declaration of inherited function Func generated by the full type declaration at line 153, and the explicit declaration of Func at line 154, both violate the second sentence of ARM 3.9.3(10) in being declarations, in the private part, of a primitive function with a controlling result of a tagged type declared in the visible part, with neither function declaration overriding a function declared in the visible part. These declarations should be detected as illegalites. (These declarations would need the parent type's Func to be inherited at the point of the private extension, yielding an implicitly declared Func in the visible part.) C3A2A02: ELABORATION_CHECK MAY FAIL The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: append to line 197 " pragma Elaborate (C3A2A02_0);" The instantiation for package C3A2A02_3 at line 198 might occur before the generic body has been elaborated, failing Elaboration_Check and propagating Program_Error. C760009: ELABORATION_CHECK MAY FAIL The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: for C760009, insert at line 86 "pragma Elaborate_Body;" The instantiation for package C76009_3.Check_1 at line 277 might occur before the generic body has been elaborated, failing Elaboration_Check and propagating Program_Error. C760010: ELABORATION_CHECK MAY FAIL The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: for C760010, insert at line 105 "pragma Elaborate_Body;" The instantiation for package C760010_2 at line 225 might occur before the generic body has been elaborated, failing Elaboration_Check and propagating Program_Error. C761007: THE CHECK FOR STRING "GHGHIJ" @376 CANNOT BE PASSED The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: replace line 376 TCTouch.Validate( "GHGHIJ", "Asynchronously aborted operation" ); with: TCTouch.Validate( "GHIJ", "Asynchronously aborted operation" ); The original code will cause the check at line 376 to be failed because the procedures C761007_0.Finalize (@87ff) and C761007_1.Finalize (@133ff) both ensure that no duplicate characters are put into the check string. (The AVO requires this change so to retain this test for finalization, as several related test programs are withdrawn.) C980001: EXTRA CALLS TO HOLD_UP.LOCK FREEZE TEST The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: comment out lines 251 & 274 (=> -- C980001_0.Hold_Up.Lock ) This modification is necessary in order to prevent the test from hanging with a queued call to the protected object C980001_0.Hold_Up. C9A007A: ABSENCE OF PRIORITIES RESULTS IN A RACE CONDITION The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: at line 33 insert "with IMPDEF;" at lines 186 & 217, insert the following delay statements: delay ImpDef.Clear_Ready_Queue; This change replaces the Ada83/ACVC 1.11 use of a lower priority in task Register with delay statements, so to ensure that the aborted tasks have time to effect their abortions. CA2009C*, CA2009F* IN TAR FORMAT: TEST FILES ARE (WRONGLY) TERMINATED WITH ^Z The AVO directs that these test programs shall be processed with the following code modification for validation under ACVC 2.1: delete the control-Z characters from each of the test files (The extraneous control characters were accidentally left in these files after they were updated for ACVC 2.1. And, yes, the tests really ought to have the ".ADA" suffix--a change from their Ada 83 ".DEP" classification.) CD30005: TEST PROGRAM'S MAIN UNIT VIOLATES ACVC NAMING CONVENTION The AVO directs that this test program may be processed with the following code modification: at lines 134 & 148 of test file cd300050, change the procedure identifier from 'CD30005' to 'CD300050'. This change will bring the main procedure name into conformity with the ACVC main-unit naming convention (and simplify ACVC processing). CE3115A: OUTPUT TO EXTERNAL FILE MAY BE BUFFERED The AVO directs that this test program may be processed with the following code modification: at line 120, insert: Flush (TXT_FILE_ONE); This code modification compensates for implementations that buffer output to external files. The program requires that, when the external file is simultaneously opened for input, the output of a Put operation can be immediately available to a Get operation (and this need not be the case, in general). FDB0A00: OVERFLOW CHECK IS MADE TOO SOON The AVO directs that this foundation file may be processed with the following code modification for validation under ACVC 2.1: move the code at lines 100..102 to precede the code at lines 95..98 (i.e., exchange the order of these two sets of code & comments) The code currently checks for potential overflow based solely on the size of requested storage; but, because alignment adjustments in what storage is allocated might effectively increase the amount of storage "used" in the allocation, the check might fail to account for all used storage. The specified code modification moves the overflow check to follow the calculation for storage (which includes alignment considerations). ::::::::::::::: ANNEX A ::::::::::::::::::::::::::::::::::::::::::::::::::::::: CXA5012: INTEGER'LAST MAY BE LESS THAN 100_000 The AVO directs that this test program may be given the following code modification for validation under ACVC 2.1: at line 86, change '100_000' to '10_000' This code modification is necessary for any implementation that defines type Integer to have a 16-bit range. CXA5015: THE FLOATING-POINT EQUIVALENCE @255 NEED NOT HOLD The AVO directs that this test program may be given the following code modification for validation under ACVC 2.1: at line 252 change '4.1' to '4.0' At line 255, T'Adjacent (TC_Float,TC_float) /= TC_Float may be True because the function result is given at greater precision for non-model 4.1 than the stored result. CXA5A01, CXA5A02, CXA5A03, CXA5A04, CXA5A09: CONSTRAINT_ERROR NEEDN'T OCCUR IF 'MACHINE_OVERFLOWS=FALSE The AVO directs that this test program may be given the following code modification for validation under ACVC 2.1: for CXA5A01, append to line 248 " if New_Float'Machine_Overflows = True then" append to line 253 " end if;" append to line 264 " if Float'Machine_Overflows = True then" append to line 269 " end if;" for CXA5A02, append to line 258 " if New_Float'Machine_Overflows = True then" append to line 263 " end if;" append to line 274 " if Float'Machine_Overflows = True then" append to line 279 " end if;" for CXA5A03: insert at line 162 " if New_Float'Machine_Overflows = True then" insert at line 174 " end if;" insert at line 310 " if New_Float'Machine_Overflows = True then" insert at line 322 " end if;" insert at line 323 " if Float'Machine_Overflows = True then" insert at line 335 " end if;" for CXA5A04: insert at line 103 " if New_Float'Machine_Overflows = True then" insert at line 115 " end if;" insert at line 204 " if New_Float'Machine_Overflows = True then" insert at line 237 " end if; if Float'Machine_Overflows = True then" insert at line 251 " end if;" insert at line 321 " if New_Float'Machine_Overflows = True then" insert at line 353 " end if; if Float'Machine_Overflows = True then" insert at line 365 " end if;" for CXA5A09: insert at line 121 " if New_Float'Machine_Overflows = True then" insert at line 133 " end if;" insert at line 287 " if New_Float'Machine_Overflows = True then" insert at line 301 " end if;" CXAF001: COMMAND_NAME RETURNS NULL STRING IF ARGUMENTS CAN'T BE PASSED The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: at line 167, replace 'Failed' with 'Comment' This change turns a Report.Failed call into a Report.Comment call, which is justified by ARM A.15(16): if the execution environment doesn't support passing arguments to a program, function Command_Name returns the null string (which is what line 167 checks for). ::::::::::::::: ANNEX B ::::::::::::::::::::::::::::::::::::::::::::::::::::::: CXB3008: C FUNCTION "atof" MIGHT NOT FUNCTION AS EXPECTED The AVO directs that this test program may be given the following code modification for validation under ACVC 2.1: at line 106, insert ' type Acc_ptr is access IC.char_array; ' at line 107, change function String_To_Double's parameter profile to: '(The_String : in IC.char_array ; End_Ptr: Acc_ptr := null)' at line 125, change 'atof' to 'strtod' This code modification imports the C library's strtod function, which has ANSI-defined semantics in the case of a string that doesn't conform to the model for a numeric value and so should enable the test to run as expected. (In some implementations of the C language, function atof will not return the expected value 0.0 in this case; its value is not defined.) (This code modification alters the previously specified one by giving the Ada function corresponding to strtod a second parameter.) CXB3009: EXPECTED STORAGE_ERROR BY REPEATED ALLOCATION MIGHT NOT OCCUR The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: comment out lines 264..287 This change simply removes the entire test block beginning at line 264, which checks that Storage_Error is raised as per the ARM B.3.1(28). There are many reasons why the expected Storage_Error might not be raised --too much available storage, too little time, even storage reclamation. CXB3010: INVOCATION OF FREE MIGHT BE ERRONEOUS The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: replicate line 199 at line 256, to update the pointer object's value: TC_chars_ptr := ICS.New_Char_Array(TC_char_array_2); The change is necessary to ensure that TC_chars_ptr has a valid pointer value; the original code references TC_chars_ptr after Free was applied to it, and so by B.3.1(51,53) that execution may be erroneous. CXB4001: TEST USES OBSOLETE PROCEDURE NAME TO_COMP VICE TO_BINARY The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: at line 198: change 'To_Comp' to 'To_Binary' The function To_Comp was defined in draft versions of the Ada 95 standard but was changed to To_Binary for the final (ARM B.4:45). CXB4007: BAD TO_BINARY (RETURN BYTE_ARRAY) COMPARISON The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: comment out lines 263..268 The Byte_Array values returned by two calls of To_Binary should not be expected to be equal, contrary to this particular check. CXB4009: COBOL CODE USED IN TEST PROGRAM IS NOT LEGAL COBOL CXB4009: COBOL CODE MAY BE UNABLE TO BE COMPILED (NO COMPILER) The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: (also) For implementations for which there is no COBOL compiler provided, this test may be processed with the grading modification to accept the inability to compile the COBOL code for a grade of Inapplicable. CXB5004: FORTRAN CODE IS ILLEGAL IN TWO PLACES The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: at line f0-79, change 'INTARR(3)' to 'INTARR' [nb: not line 81] at line f0-83, change 'STR' to 'STR *7' The changes specified above are necessary in order to produce a legal Fortran program to be used for the test program's interfacing checks. ::::::::::::::: ANNEX C ::::::::::::::::::::::::::::::::::::::::::::::::::::::: BXC6A02: TYPE FXC6A00.NONVOLATILE_TAGGED INHERITS VOLATILITY The AVO directs that this test program may be processed with the following grading modification for validation under ACVC 2.1: accept compiler error diagnostics for lines 159 & 188 The two cited lines use an object of type FXC6A00.NonVolatile_Tagged in ways that depend that it indeed be non-volatile. But this type inherits volatility from its parent. (Note that a similar error occurs in BXC6A03, which is withdrawn for other reasons.) FXC6A00: PRAGMA VOLATILE APPLIED @103,113 VIOLATES 13.1(10) The AVO directs that this foundation file be given the following code modification for validation under ACVC 2.1: comment out lines 103 & 113 The application of a pragma Volatile to derived types Volatile_Composite and Volatile_Array violates 13.1(10), for these types are untagged derived types (with tagged components) whose parent types are by-reference types (by 6.2:5,8). The only test program that references these two types is BXC6A03, which is withdrawn (for a similar reason). Three other test programs use this foundation file. ::::::::::::::: ANNEX D :::::::::::::::::::::::::::::::::::::::::::::::: ::::::: CXD1008: THE FLOATING-POINT EQUIVALENCE @228 NEED NOT HOLD The AVO directs that this test program may be given the following code modification for validation under ACVC 2.1: comment out the check @228..232 This check may fail if an implementation uses different representations (lengths) of the compared values--one possibly the register contents of evaluation, the other a stored copy--, as the value is not a model number. CXD2004: EXECUTION CORRECTNESS DEPENDS ON INITIAL READY-QUEUE ORDER The AVO directs that this test program may be given the following code modification for validation under ACVC 2.1: at line 204 insert 'delay 0.0;' The problem is that if Sub_Task_B is initially at the head of the ready queue for the default priority, then when Driver blocks on its later call to Sub_Task_A's entry (which it will, since this task hasn't yet run, to wait at its accept statement), Sub_Task_B will be able to run and register via the protected object unexpectedly, invoking Report.Failed. This delay statement will ensure that in the ordering above, Sub_Task_B will be put at the tail of its ready queue, with Sub_Task_A then at the head. CXD4008: WRONG QUEUING POLICY; MULTIPROCESSORS MAY FAIL P.O. & TASK CHECKS The AVO directs that this test program shall be processed with the following code modifications for validation under ACVC 2.1: at line 61, change 'FIFO_Queuing' to 'Priority_Queuing' at line 134, change 'Last_Entry >=5;' to 'Last_Entry >5;' at line 379, append ' Checker.E5;' at line 170, append ' e1_gate, e2_gate, e3_gate, e4_gate, e5_gate : Boolean := True;' at line 176, change 'when Gate =>' to 'when Gate and e1_gate =>' at line 183, insert 'e1_gate := false;' and make similar changes, respectively, for 'e2_gate' through 'e5_gate', at lines 186/193, 196/203, 206/213, & 216/223 The first change is necessary as a basis for this test: the textual order of selection for equal-priority calls is only required for the Priority_Queuing policy, not for FIFO_Queuing (although implementations might simply use this behavior for both)! The second set of changes addresses the problem of concurrent execution of the environment task, and the third addresses the problem of processing the set of task-entry calls (in effect, the particular accept statement is closed after a call has been accepted). With the original code, the environment task can run concurrently with the higher-priority "T" type tasks, and can check a global results array that may not have yet been fully valued by the entry selections, yielding FAILED wrongly. Further, in the checks for task entries, a multi-processor can also deviate from the expected execution order, as the first tasks whose entry calls are processed by the selective accept statement at lines 175ff can make a second like entry call and be handled by this same selective accept (instead of by the one at lines 263ff, as intended). CXD6001: "VICTIM_TYPE" TASKS NEED NOT COMPLETE BEFORE CHECK_RESULTS IS CALLED The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: at line 114 insert 'with ImpDef;' at lines 270, 285, & 300 append ' Delay ImpDef.Clear_Ready_Queue;' This delay statement will enable the Victim_Type tasks to complete before Check_Results is called. CXD6002: TASK WEAPON IS NOT TERMINATED FOR MULTI-PROCESSORS The AVO directs that this test program may be given the following code modification for validation under ACVC 2.1: insert immediately after line 348: CXD6002_1.Done; (i.e., replicate line 357 here) On a non-uni-processor system, this code is necessary to terminate the task CXD6002_1.Weapon (line 110). CXD8002: TO_DURATION(RT.TIME_SPAN_UNIT) MIGHT = 0.0 CXD8002: MULTIPROCESSOR MAY HAVE DIFFERENT READINGS OF VOLATILE GLOBAL The AVO directs that this test program may be processed with the following code modifications for validation under ACVC 2.1: insert at line 169: 'Delay_Amount := RT.To_Time_Span(Duration'Small);' and comment out line 170 ('--Delay_Amount := RT.Time_Span_Unit;') The conversion To_Duration(Delay_Amount) at line 174 can yield 0.0, since Delay_Amount was assigned Ada.Real_Time.Time_Span_Unit, which may be smaller than Duration'Small. (also) at line 73, prepend 'if Avaliable_Entry'Count > 0 then ' at line 79, append ' end if;' These changes guard the Background_Passive task's accept statement from being executed when there is no call queued, thus preventing the task from hanging on this accept when the Background_Active task termintates (and never calls again). ::::::::::::::: ANNEX E ::::::::::::::::::::::::::::::::::::::::::::::::::::::: BXE2009: ITEM PARAMETER FOR WRITE MUST BE OF A BASE SUBTYPE (13.13.2:36) The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: change the type of parameter Item at lines 93 & 98 from: Is_Limited_With_Attrs to Is_Limited_With_Attrs'Base The ARM 13.13.2(36) requires that the subtype of the Item parameter "shall be the base subtype if scalar," and the above change conforms. BXE2012: TYPO GIVES WRONG TYPE FOR CONTROLLING_PARM The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: change line 178 from: v procedure Primitive_Op_2 (Controlling_Parm : access Tagged_Type_1; to: procedure Primitive_Op_2 (Controlling_Parm : access Tagged_Type_2; ^ This change corrects a typographical error in the declaration of procedure Primitive_Op_2, which should be a primitive for type Tagged_Type_2 rather for Tagged_Type_1. The type of parameter Controlling_Parm thus must be Tagged_Type_2. BXE4001: REMOTE ACCESS TYPE DECLARATION IS AN UNINTENDED ILLEGALITY The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: insert at line 90: "private" The code modification above will end the visible part before the cited remote access type declaration, making it no longer remote, and hence no longer in violation of E.2.2(9). (And the intended error at line 91 will now exist.) CXE4003: PRAGMA REMOTE_CALL_INTERFACE @131 APPLIES ONLY TO THE GENERIC UNIT The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: at line 175 insert 'pragma Remote_Call_Interface(CXE4003_Part_B2);' at line 178 insert 'pragma Remote_Call_Interface(CXE4003_Part_B3);' at line 181 insert 'pragma Remote_Call_Interface(CXE4003_Part_B4);' at line 184 insert 'pragma Remote_Call_Interface(CXE4003_Part_B5);' As AI95-00041 directly states, "Program unit pragmas within a generic unit and applying to the generic unit itself do not apply to instances of the generic unit." But this test program's pragma at line 131 was wrongly expected to apply to the instantiations at lines 173..183. The specified code modification correctly applies the pragma to each instance. CXE4006: TEST EXPECTS WRONG TYPE'TAG The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: at line 772, change "CXE4006_Part_A2.A2_Tagged_Type" to "CXE4006_Part_A1.A1_Tagged_Type_2" ^ ^ ^^ The call of procedure Wrapped_Around (within CXXE4006_Part_A2.Call_B, which is invoked at line 458) at line 700 has an actual parameter A1_2_Obj, which is declared at line 420 as of type A1_Tagged_Type_2. CXE5003: PARAMETER LAST FOR READ MIGHT NEED A VALUE The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: append to line 240 after "begin": ' Last := Item'First;' It is possible that the system might call Read and that the execution would be erroneous since out parameter Last is not assigned a value. ::::::::::::::: ANNEX F ::::::::::::::::::::::::::::::::::::::::::::::::::::::: [null] ::::::::::::::: ANNEX G ::::::::::::::::::::::::::::::::::::::::::::::::::::::: CXG1004: TEST'S CHECKS FOR EXCEPTIONS WITH PLUS_/MINUS_ONE ARE WRONG The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: at lines 294, 307, 320, & 333 replace characters '_i' with '_One' The required change makes these assignments use the intended variable. The test was coded with a simple typographical error in what are checks of a clearly defined requirement--that Constraint_Error be raised for the complex elementary functions Arctanh & Arccoth with a parameter of plus of minus one. CXG2002: INTERMEDIATE RESULTS IN AN EXPRESSION CAN OVERFLOW The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: at lines 99 & 279, add parens to change the expression: 'Mre * abs Expected * Real'Model_Epsilon' to: 'Mre *(abs Expected * Real'Model_Epsilon)' ^ ^ This change will ensure that the expression is not evaluated by multiplying its two large terms together and overflowing. CXG2004: CALCULATION OF REPRESENTABLE X AND X/3 IS INCORRECT The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: comment out lines 455, 456, & 457 (calls to Sin_Check & Cos_Check) The two subprograms Sin_Check & Cos_Check incorrectly expect that the statement "Y := (X + Y) - X;" will effectively truncate the representation of Y; but an implementation may evaluate such an expression with infinite precision, effectively rendering it a no-op. As a result, later checks in the test program may be failed. CXG2008: CONSTRAINT_ERROR NEED NOT BE RAISED IN REAL'MACHINE_OVERFLOWS=FALSE The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: for each of lines 216, 233, 489, 506, 758, 775 append (after 'begin'): ' if Real'Machine_Overflows then' for each of lines 220, 237, 493, 510, 762, & 779 prepend (before 'exception'): 'end if; ' These code modifications correct the test program's incorrect assumption that Constraint_Error must be raised by complex division by zero, which is contrary to the allowance given by the Ada 95 standard G.1.1(40). CXG2011: LOG(0.0) MUST RAISE CONSTRAINT_ERROR, NOT ARGUMENT_ERROR The AVO directs that this test program shall be given the following code modification for validation under ACVC 2.1: at line 394: change 'Failed' to 'Comment' This change allows the non-conforming raising of Argument_Error, and so does not penalize implementers for meeting the test's original requirement. However, implementations should raise Constraint_Error in this case, as per A.5.1(28,29), which will be required under ACVC 2.2 validation. CXG2012: INTERMEDIATE RESULTS IN AN EXPRESSION CAN OVERFLOW The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: at line 124, change the expression: 'Mre * abs Expected * Real'Model_Epsilon' to: 'Mre *(abs Expected * Real'Model_Epsilon)' This change will ensure that the expression is not evaluated by multiplying its two large terms together and overflowing. CXG2013: TAN(Y) @302 RAISES CONSTRAINT_ERROR WHEN Y = 0.5 : CALCULATION OF ERROR BOUND IS INCORRECT The AVO directs that this test program shall be processed with the following code modifications for validation under ACVC 2.1: at line 89: change '1000' to '1001' The change should preclude an even factor of 0.5 in the expression at line 295, and hence the even results of Pi for X and Pi/2 for Y --which is sufficiently near a pole of the Tan function that it may overflow (A.5.1:34). (also) comment out line 434 (the call to Special_Angle_Test) By removing the call to the flawed routine, the test program's other, valid, checks can be made. The Special_Angle_Test is too lenient, re Tan with cycle=360.0 degrees, and too severe, re cycle in radians. CXG2014: TAYLOR SERIES IN SUBTRACTION_TEST LACKS SUFFICIENT TERMS The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: comment out line 345 (the call to Subtraction_Error_Test) In the Subtraction_Error_Test, there is an approximation made of a Taylor Series expansion for calculating a value; this approximation however omits too many terms and so is inaccurate. CXG2016: CONVERSION TO DEGREES IN INDENTITY_1_TEST IS WRONG The AVO directs that this test program shall be given the following code modification for validation under ACVC 2.1: comment out lines 417 & 418 These lines contain the only calls to the incorrect procedure Indentity_1_Test. The "conversion to degrees" at line 280 is not sensible, and will wrongly cause the test to be failed. CXG2017: ERROR BOUND FOR TANH(X) NOT CORRECT FOR X CLOSE TO ZERO The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: change line 212, by inserting parens, from X := (B - A) * Real (I) / Real (Max_Samples) + A; to X := (B - A) *(Real (I) / Real (Max_Samples))+ A; ^ ^ comment out line 256 (the first call to Identity_Test) The first code modification removes the potential for overflow, forcing one of the allowed orders of evaluation for the original code. The second change removes the invocation of Identity_Test that checks Tanh values that are too close to zero for the test's error bounds. CXG2020: INTERMEDIATE RESULTS IN AN EXPRESSION CAN OVERFLOW The AVO directs that this test program may be processed with the following code modification for validation under ACVC 2.1: at line 119, change the expression 'Mre * abs Expected * Real'Model_Epsilon' to: 'Mre *(abs Expected * Real'Model_Epsilon)' This change will ensure that the expression is not evaluated by multiplying its two large terms together and overflowing. ::::::::::::::: ANNEX H ::::::::::::::::::::::::::::::::::::::::::::::::::::::: LXH* (13 FILES): LXH* TESTS VIOLATE ACVC NAMING CONVENTION The AVO directs that these test programs may be processed with the following code modifications for validation under ACVC 2.1: change each of the test files (file name given with sequencor delimited by '/' for conpsicuosness) as indicated by "=>" ("to"): for LXH4001/2, at lines 141 & 174, 'LXH4001' => 'LXH40012' for LXH4002/2, at lines 131 & 138, 'LXH4002' => 'LXH40022' for LXH4003/3, at lines 96 & 103, 'LXH4003' => 'LXH40033' for LXH4004/3, at lines 94 & 103, 'LXH4004' => 'LXH40043' for LXH4005/3, at lines 94 & 107, 'LXH4005' => 'LXH40053' for LXH4006/3, at lines 92 & 101, 'LXH4006' => 'LXH40063' for LXH4007/3, at lines 94 & 103, 'LXH4007' => 'LXH40073' for LXH4008/4, at lines 98 & 105, 'LXH4008' => 'LXH40084' for LXH4009/3, at lines 97 & 112, 'LXH4009' => 'LXH40093' for LXH4010/3, at lines 94 & 103, 'LXH4010' => 'LXH40103' for LXH4011/3, at lines 89 & 100, 'LXH4011' => 'LXH40113' for LXH4012/3, at lines 94 & 100, 'LXH4012' => 'LXH40123' for LXH4013/3, at lines 98 & 103, 'LXH4013' => 'LXH40133' LXH4011: ERRORS BEFORE AND AFTER PRAGMA RESTRICTIONS CAN'T BOTH EXIST The AVO directs that this test program shall be processed with the following grading modification for validation under ACVC 2.1: accept a compile-time error detection of the violation at line 67 of file LXH40112 as passing (even though link-time detection of the earlier-compiled violations in LXH40110 cannot be achieved) The test wrongly includes violations of the configuration pragma Restrictions in units compiled both before and after the pragma is processed. Later units may be rejected as violations, and so the implementation cannot reach the link stage and detect the previously compiled violations. LXH4013: MAIN SUBPROGRAM OF "L" TEST CAN BE EXECUTED The AVO directs that this test program shall be processed with the following code modification for validation under ACVC 2.1: append at line 97 of file LXH40133: " with LXH4013_1;" This modification makes the main subprogram depend on a unit that contains a violation of pragma Restrictions(No_Delay), thus preventing the subprogram from being able to be executed. ========================================================================