!section 11.06 (00) Dan Lehman 91-09-22 83-01427 !version 1983 !topic Subtype checks and optimization FRTeam: Let us explore optimization disputes further, perhaps to push back the limits a bit. The cases presented here are more or less what Norm mused about in yielding his resistance to "PROC( )" which was discussed in FRN910502-a. Norm's note of concern, and Robert's response to it, are attached to this FRN. This FRN addresses two similar cases: CC3125C 30 GENERIC 31 GEN_FLO : IN FLO; --range of -5.0 .. 5.0 32 PACKAGE P IS 33 PAC_FLO : FLT := GEN_FLO; --the sole stmnt in pkg P2 ... --i.e., a dead-var. assignment 50 DECLARE 51 PACKAGE P2 IS NEW P(IDENT_FLT(-5.1)); --must raise C_E? 52 BEGIN 53 FAILED ("NO EXCEPTION RAISED - 2"); ------------------------------------------------------------------- CE3704C 108 BEGIN --here, X is of subtype INT (1..10), 109 GET (FT, X); --but X is further constrained to 1..5; --input value is 8 110 FAILED ("CONSTRAINT_ERROR NOT RAISED - " & 111 "OUT OF RANGE"); In neither case is there, as Norm wondered, a direct link to 11.6--the two affected subtype checks are not attached to operations that may be omitted. Note that the issue in the 2nd, I/O, case is not with the check of the read input value as per 14.3.7(8), but with the additional check of 6.4.1(7). If some felt that a loop to skip filed values ought to not succeed on bad input for I in INTEGER(1)..5 LOOP --skip next 5 integers begin GET(FT, X); exception when DATA_ERROR => <...> end; end loop; --i.e., optimization ought not to remove data checks--does the distinction above answer that concern (that the data integrity re instantiated subtype will be maintained, but the additional subtype check might be skipped)? In answer to Norm's highlighted passage below, it seems that we produce an oddity if (1) but not (2), below, may raise no exception: PROC() --(1) may be skipped, by 11.6(7) PROC() --(2) require the subtype check to be made One cannot allow the operation of (1) to be skipped and yet require that a subtype check be made there, for there's no resultant value to check. But to require the subtype check to be made for (2) would make the making of the subtype check dependent on the form of the expression, which doesn't seem reasonable, does it? ---Dan ------- * ------------------------------------------------------------------------------- . From ncohen@watson.ibm.com Fri May 3 11:01:29 1991 . Subject: FRN910502-a: PARAMETER OPTIMIZATION [...] This note is just to express concern about the general principle Robert stated in his note as justification for ignoring what he, naively taking my assertion at face value, believed to be the only tenable reading of the RM: > I find such nit-picking to be unsupportable. The clear idea of 11.6 is > to stop CONSTRAINT_ERROR from providing silly barriers to optimization. The problem with this "pragmatic" attitude is knowing where to draw the line. **>> Do we also go on to allow other optimizations, not hinted at in **>> 11.6 (for example, removing the check that the value of the actual is **>> in the subtype of the formal if the subprogram body never refers to the **>> formal), on the grounds that requiring such a check is a "silly barrier **>> to optimization" and the "spirit of 11.6" is to eliminate such barriers? To what extent will we allow compilers to change the observable behavior of the program on the grounds that (1) the new behavior can be achieved more efficiently than the behavior that the program called for and (2) the programmer probably didn't mean to be taken so literally anyway? If we take such reasoning too far, the result is not at all pragmatic. A programmer is entitled to know the rules of the game and to expect that a compiler will adhere to them. ------------------------------------------------------------------------------ . From dewar@cs.NYU.EDU Fri May 3 11:14:40 1991 . Subject: Re: FRN910502-a: PARAMETER OPTIMIZATION The philosophy behind 11.6 is quite simple to state -- you don't need to raise constraint-error if you can instead give "correct" results, i.e. results that corresponded to what the programmer intended. Now of course this is not well defined, but I think we do better to evaluate disputes on the basis of trying to understand the proper application of this philosophy, rather than reading the wording of 11.6, which is in my opinion discredited at this stage. "If we take such reasoning too far, the result is not at all pragmatic" absolutely true, so we must avoid doing so (taking such reasoning too far). One of the troubles for me with 11.6 is that it allows transformations which clearly are taking things too far (and not giving "correct" results, as in my TEST_OVERFLOW function example). It's a tricky area, but not one where careful legalistic exogesis of 11.6 will prove very helpful. ============================================================================== ***************************************************************************** !section 11.06 (00) Norman Cohen 91-09-27 83-01428 !version 1983 !topic Subtype checks and optimization !reference 83-01427 > On the specific examples: if a compiler can tell that passing a parameter > is unnecessary because the formal is never used, I would hate to see the > ACVC preventing this optimization. Particularly, if the subprogram is > inlined, since, in that case the parameter passing is likely to look like > a plain unnecessary assignment, which can "obviously" be killed. Yes. An obvious example is package ASSERTION_PACKAGE is CHECKING_ASSERTIONS : constant BOOLEAN := FALSE; procedure ASSERT (ASSERTION: in BOOLEAN); pragma INLINE (ASSERT); ASSERTION_ERROR : exception; end ASSERTION_PACKAGE; package body ASSERTION_PACKAGE is procedure ASSERT (ASSERTION: in BOOLEAN) is begin if CHECKING_ASSERTIONS and then not ASSERTION then raise ASSERTION_ERROR; end if; end ASSERT; end ASSERTION_PACKAGE; With CHECKING_ASSERTIONS set statically to FALSE, I would expect the call ASSERT (X = Y/Z); -- predefined "=" and "/" to be optimized away completely, since the only possible effect of evaluating actual parameter is to raise an exception. Unfortunately, if the assertion contains calls on user-defined functions, e.g. ASSERT (A(J) in MAX_ELEMENT(A(1 .. J-1)) .. MIN_ELEMENT(A(J+1 .. N))); evaluation of the actual parameter seems unavoidable (unless MAX_ELEMENT and MIN_ELEMENT are also inlined and clearly side-effect-free). ***************************************************************************** !section 13.02 (10) Norman Cohen 91-09-26 83-01425 !version 1983 !topic Adding padding to a packed array !reference AI-00555/07 The second paragraph of the summary begins, "An implementation is allowed to pad an array to a storage boundary...." Does this mean "to the next addressable storage boundary," or "to a storage boundary of the implementation's choosing"? Clearly a packed array of six five-bit components can be padded on a machine with eight-bit bytes with two padding bits, so that A'SIZE = 32. But given a packed array type T with seven eight-bit components, is the implementation allowed to add eight more bits of padding, so that T'SIZE = 64 rather than 56? This would mean that if the programmer then declared type TEN_TIMES_T is array (1 .. 10) of T; pragma PACK(TEN_TIMES_T); for TEN_TIMES_T'SIZE use 560; the length clause would be rejected, but the implementation could use double-register load instructions to extract components of a TEN_TIMES_T object. My inclination is that an implemenation SHOULD be allowed to do this. The programmer can always write for T'SIZE use 56; to force this not to happen. AI-00556/04 (so far only a work item) would require this length clause to be accepted; with T'SIZE fixed at 56, the AI would also require the length clause specifying TEN_TIMES_T'SIZE as 560 to be accepted. ***************************************************************************** !section 13.02 (10) Robert Dewar 91-09-26 83-01426 !version 1983 !topic Adding padding to a packed array !reference 83-01425 I entirely agree with Norm here. Let implementation do whatever padding it likes, and allow user to restrict this freedom with length clause on aggregate object. Fly in the ointment: unconstrained array types ***************************************************************************** !section 14.02.02 (04) J. Goodenough 91-10-07 83-01429 !version 1983 !topic Test dispute regarding DATA_ERROR !reference AI-00870 ------------------------------------------------------------------------------ 1 lehman@ida.org Thu Apr 26 20:44 83/3508 FRN 900426-A: DATA_ERROR 2 dewar@acf2.NYU.EDU Fri Apr 27 04:35 56/2832 Re: FRN 900426-A: DATA_E 3 jbg@SEI.CMU.EDU Fri Apr 27 11:57 13/520 Re: FRN 900426-A: DATA_ER 4 brashear@ajpo.sei Fri Apr 27 14:17 45/2232 Re: FRN 900426-A: DATA_ER 5 jbg@SEI.CMU.EDU Fri Apr 27 16:25 33/1571 Re: FRN 900426-A: DATA_ER 6 @IBM.COM:NCOHEN@YK Mon Apr 30 10:45 23/986 FRN 900426-A: DATA_ERROR 7 dewar@acf2.NYU.EDU Mon Apr 30 11:14 36/1816 Re: FRN 900426-A: DATA_E 8 @IBM.COM:NCOHEN@YK Mon Apr 30 12:06 41/2212 FRN 900426-A: DATA_ERROR 9 dewar@acf2.NYU.EDU Mon Apr 30 12:27 13/628 Re: FRN 900426-A: DATA_E 10 dewar@acf2.NYU.ED Mon Apr 30 12:27 10/278 Re: FRN 900426-A: DATA_E 11 dewar@acf2.NYU.ED Mon Apr 30 12:31 22/958 Re: FRN 900426-A: DATA_E 12 ploedere@tartan. Tue May 8 22:39 15/444 Re: FRN 900426-A: DATA_E ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From lehman@ida.org Thu Apr 26 20:44:55 1990 . To: frteam@ajpo.sei.cmu.edu . Subject: FRN 900426-A: DATA_ERROR . Cc: lehman@ida.org FRTeam: The following dispute has been received concerning two tests that check for the raising (or not) of DATA_ERROR. In FRN 880705 another dispute was raised concerning DATA_ERROR: a BOOLEAN value was written to a shared file and read into a CHARACTER object; the test expected DATA_ERROR to be raised. The FRT agreed that the check should not be required (and so the program continues with a perhaps strangely valued CHARACTER object-- = erroneous?). The present dispute differs in that DATA_ERROR is not required to be raised (Report.Comment follows the Read, not Report.Failed), but the imple- mentation DOES raise an exception--CONSTRAINT_ERROR. Is not only ignoring the type check, but otherwise raising an exception other than DATA_ERROR acceptable? ---Dan ------- * ps: I WILL get to answering Robert re FRN 900409! -------------------------------------------------------------------------- CE2205B & CE2405A The design of these tests is questionable. The tests check whether or not DATA_ERROR is raised by input of incorrect data. However, they print failed if some other exception is raised. This doesn't follow; the program is effec- tively erroneous after hte bad read (the effect being dimelar to that of an unitialized variable), and nearly anything can happen in such a case. If Sequential/Direct_IO does not make the check, it is likely that the parameter-passing mechanism will. That means that a very reasonble thing for an implementation to do is to raise CONSTRAIN_ERROR at the point of the READ (the assignment of the formal parameter into the actual having failed). The interpretation forced by these tests is particularly onerous, because it effectively requires that the implementation of Sequential/Direct_IO not be written in Ada. I think that this result is not at all what the designers of the language intended. (Notice that the "obvious" Ada solution does not work--testing for membership. The test Item in Element_Type can fail only for erroneous programs--therefore all compilers that I am aware of do not actually generate code for this check.) ---------------------------------------------------------- Excerpts from the CE2205B: 23 TYPE DWARFS IS (SLEEPY, DOC, HAPPY, GRUMPY, DOPEY, BASHFUL, 24 SNEEZY); 25 26 TYPE LAKES IS (HURON, ONTARIO, MICHIGAN, ERIE, SUPERIOR); 65 WRITE (FILE1, SLEEPY); ['POS = 0] 66 WRITE (FILE1, SNEEZY); ['POS = 6] 67 WRITE (FILE1, DOC); 68 WRITE (FILE1, HAPPY); 81 READ (FILE2, LAKE); 82 IF LAKE /= HURON THEN 83 FAILED ("INCORRECT VALUE FOR READ - 1"); 84 END IF; 85 86 BEGIN 87 READ (FILE2, LAKE); [value > lakes'Last'Pos?] 88 COMMENT ("NO EXCEPTION RAISED FOR READ WITH INVALID " & 89 "ELEMENT"); 90 EXCEPTION 91 WHEN LAKES_IO.DATA_ERROR => 92 COMMENT ("DATA_ERROR RAISED FOR READ WITH " & 93 "INVALID ELEMENT"); 94 WHEN OTHERS => 95 FAILED ("WRONG EXCEPTION RAISED"); ============================================================================== ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From dewar@acf2.NYU.EDU Fri Apr 27 04:35:27 1990 . To: frteam@ajpo.sei.cmu.edu, lehman@ida.org . Subject: Re: FRN 900426-A: DATA_ERROR This is a badly flawed test which should never have got past quality assurance procedures. First of all, even in its own terms, the test is nonsense. Even if the implementation does make a check on incoming data, there is nothing in the examples of the test that would suggest that the data values read are not part of the type for the read. The author apparently assumes without any justification that by default enumeration types are represented using a range 0 .. n, when of course there is no such requirement. Second, the RM says that this check can be omitted "if it is too complex". At the very least this should have clued the test writer in to making this a DEP test. We all know that the whole concept of such vague statements is flawed in the RM, and such a statement should raise a red flag. Note that the RM does NOT require appendix F to detail whether or not the check is made, except under the general umbrella of F. (8). If we were being legalistic, we could insist that the implementation in question is illegitimate if it does not include in appendix F a statement that these checks are omitted because "they are too complex". However, tests must be written in the context of the real world, and the obvious situation is that most implementations do not make the check, regardless of whether or not they document this, and users generally do not expect a check to be made. The status of a program where the checks are omitted is not addressed by the RM. The best guess is that the result is erroneous, but this is not stated. So in short what we have here is at best a DEP test that is only applicable to implementations which make the check, and the RM has nothing to say at all about its behaviour if the check is not made. CONSTRAINT_ERROR is a most polite result compared to what might happen. This test should never have been written, even a cursory examination of the test objective should have raised a red flag. We really must have quality assurance procedures in place to review tests. Noone knows Ada well enough to on their own avoid serious misconceptions, particularly when to write tests one needs to know both Ada and its typical implementation models in the real world. I have the feeling that this is yet another test where only the author looked at it, and wrote the test with some severe misconceptions. How much more junk like this will be uncovered? In case I am not clear, my recommendation is that we remove the test from the suite [and if possible to avoid embarrasment we change the history books to pretend that this test never existed - although I guess such corrective actions are going out of style even in the "unfree" world]. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From jbg@SEI.CMU.EDU Fri Apr 27 11:57:45 1990 . To: lehman@ida.org (Dan Lehman) . Subject: Re: FRN 900426-A: DATA_ERROR . Sender: jbg@SEI.CMU.EDU I really need to see more of the test to check the argument. The problem with excerpting tests is that the excerpts considered relevant are chosen with a particular view in mind, whereas the excluded parts might suggest a different view. The excerpts are helpful in focusing attention, but I need to see the whole test to be sure the excerpts are the right ones. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From brashear@ajpo.sei.cmu.edu Fri Apr 27 14:17:26 1990 . To: lehman@ida.org (Dan Lehman) . Cc: frteam@ajpo.sei.cmu.edu, brashear@ajpo.sei.cmu.edu . Subject: Re: FRN 900426-A: DATA_ERROR The disputing implementor is correct; DATA_ERROR need not be raised "if performing the check is too complex" (RM 14.2.2/4). On the other hand, assigning the value read to the actual parameter (as part of the return- from-procedure processing) can be expected to raise CONSTRAINT_ERROR, since the value read does not satisfy the requirements of the actual's subtype. In the current version of the Implementers' Guide, an "implementation guideline" for the objective of test CE2205B dictates that raising CONSTRAINT_ERROR is grounds for failure. Another guideline for the objective warns the ACVC implementor to avoid the very possibility raised by this dispute; in fact, explicit direction is given on avoiding this possibility. Here is where the test deviates from (the current version of) the IG. Robert: First, the flaw in the test is not what you suggest -- it's not that DATA_ERROR is expected; the test writer clearly avoids such a requirement. Therefore, the phrase "if it is too complex" does not apply to the dispute. Neither is it the case that only the author of the test looked at it. The problem arises from reading one implementation guideline without considering implications that are expressed in a later guideline (which may not even have been in the applicable IG version). Second, it may be that the best target for a QA function is the IG. We all profess that it is better to uncover errors at the requirements or the design stage than at the code/test stage, so maybe a thorough review of the IG is in order. After all, the IG is the design document for the ACVC, and specifies requirements for the individual tests. The current IG version is a result of incorporating the AJPO-approved, with no funding being made available for detection or correction of errors. As part of that revision effort, reviewers were solicited (on a volunteer basis, unfortunately). Only two people outside the AMO/contractor organization agreed to review parts of the document; neither lived up to his intentions. Phil ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From jbg@SEI.CMU.EDU Fri Apr 27 16:25:07 1990 . To: lehman@ida.org (Dan Lehman) . Cc: frteam@ajpo.sei.cmu.edu . Subject: Re: FRN 900426-A: DATA_ERROR . Sender: jbg@SEI.CMU.EDU This test should be withdrawn. It is incorrect for the reason cited by the challenger, and for other reasons as well. The test writes a sequence of DWARFS values and then opens the file with data type LAKES and tries to read the values with the following statements: 81 READ (FILE2, LAKE); 82 IF LAKE /= HURON THEN 83 FAILED ("INCORRECT VALUE FOR READ - 1"); 84 END IF; The exception handler for these statements only has an alternative for the exception INCOMPLETE, and yet, an implementation can validly raise DATA_ERROR for this READ statement since the written value is in fact not a value of the type LAKES. Robert makes a similar point when he complains that the test assumes that the representation of SLEEPY and HURON is the same, but I think the stronger point can be made that even if the representations are the same, the implementation can raise DATA_ERROR (e.g., if the implementation chooses to code the file with type information -- unlikely, but I don't think Ada requires that READs operate as a kind of unchecked conversion). In any event, the Implementation Guideline requesting a check that CONSTRAINT_ERROR not be raised should have been replaced when the more explicit guideline was written describing how to create a situation in which either DATA_ERROR or no exception are the only possibilities. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From @IBM.COM:NCOHEN@YKTVMV Mon Apr 30 10:45:52 1990 . To: lehman@ida.org . Cc: frteam@ajpo.sei.cmu.edu . Subject: FRN 900426-A: DATA_ERROR Dan: 1. I find no support in 14.2.2(4) or 14.2.4(4) for your assertion that execution is erroneous after a READ with a bad input value. AI-00870, currently only an empty template, addresses this question. I would be far more conservative, restricting erroneous execution to the *USE* of a scalar subcomponent of the value obtained by a call on READ with bad data. Our energies should be directed towards narrowing both the circumstances in which execution is considered erroneous and the possible behaviors that may result. I find it unhelpful to assert that when bad data is read "nearly anything can happen." 2. It is clear that a check for DATA_ERROR can be omitted. In such cases it is perfectly reasonable for the parameter-passing mechanism to raise CONSTRAINT_ERROR. Thus the test is invalid. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From dewar@acf2.NYU.EDU Mon Apr 30 11:14:07 1990 . To: NCOHEN@IBM.COM, lehman@ida.org . Subject: Re: FRN 900426-A: DATA_ERROR . Cc: frteam@ajpo.sei.cmu.edu In response to Norm's message, I agree that this restriction may be appropriate (only erroneous if the value is used), and maybe I even had this in mind when I wrote the original comment, I can't remember. From a formal point of view, it is not clear that the errroneousness can be "put off" this way. After all assigning a scalar value that is undefined is erroneous (perhaps it shouldn't be, but it is!) and the read sure seems like an assignment to me. Maybe it is "unhelpful" to say that when bad data is read, "nearly anything can happen", but it is probably a true reflection of implementors current understanding. Certainly if the bad data is used, this is the case, but even if it is not, I can imagine the read causing trouble. Here is an example: you are reading data that is a sequence of variable length arrays with a length of 1-10. The data format writes the length as the first word. On input, the compiler believes that the first word it reads is a length in the range 1-10, and does not check, believing that it is valid to omit this check. Now of course a bad length can cause storage over-writing etc. I know that Norman has an abstract formal view in which erroneousness should be contained and restricted, but you can't forget that what is going on here is machine language running amuck, not some formal model that somehow has bugs in it. The requirement that the read not cause unrestricted bad effects is, from an implementation point of view, if not from a formal point of view, equivalent to a requirement for runtime checking, which, as Norman points out, appears NOT to be required. You can't have it both ways Norman! ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From @IBM.COM:NCOHEN@YKTVMV Mon Apr 30 12:06:11 1990 . To: dewar@acf2.NYU.EDU, lehman@ida.org . Cc: frteam@ajpo.sei.cmu.edu . Subject: FRN 900426-A: DATA_ERROR >>After all assigning a scalar value that is undefined is erroneous >>(perhaps it shouldn't be, but it is!) and the read sure seems >>like an assignment to me. Actually, something funny is going on in the body of READ, with the bits found in the file "cast" to the type of the actual parameter. The bits themselves are not an undefined value. It is only once these bits have been placed in the target variable, and thus cast, that there are grounds for regarding the bits as representing an undefined value. From an "abstract formal point of view" (why do I get the feeling that *I* am being typecast?) I don't see this as an erroneous use of a undefined value. If we had any basis for assuming that the body of READ used UNCHECKED_CONVERSION to achieve this type cast, we might regard it as an erroneous conversion that fails to "maintain the properties that are guaranteed by the language for objects of the target type"--but we don't have any basis for making that assumption. >>Here is an example: you are reading data that is a sequence of variable >>length arrays with a length of 1-10. The data format writes the length >>as the first word. On input, the compiler believes that the first word >>it reads is a length in the range 1-10, and does not check, believing >>that it is valid to omit this check. Now of course a bad length can >>cause storage over-writing etc. I hope you don't know of any real implementations that act this way! I see no justification for basing the decision about which storage units should be written into on the contents of the file rather than the address and length of the actual parameter. Nor could I imagine an implementation overwriting array dope information associated with the actual parameter with array dope information found in the file. In the case where the actual was an unconstrained record with discriminants, I would be willing to demand a check on the discriminant values found in the file. If and when AI-00870 comes before the ARG, the discussion should prove to be interesting! ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From dewar@acf2.NYU.EDU Mon Apr 30 12:27:15 1990 . To: NCOHEN@IBM.COM, dewar@acf2.NYU.EDU, lehman@ida.org . Subject: Re: FRN 900426-A: DATA_ERROR . Cc: frteam@ajpo.sei.cmu.edu Well you (Norman may imagine that a discriminant check should be made, but how on earth did you deduce that? I don't see that suggestion in the RM). I would frankly be surprised if there do NOT exist implementations that behave in the way I described, it's certainly what I as a user would expect from the description in the RM, which I take to mean that I had better make sure the data on the file is OK, otherwise who knows what will happen? ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From dewar@acf2.NYU.EDU Mon Apr 30 12:27:26 1990 . To: NCOHEN@IBM.COM, dewar@acf2.NYU.EDU, lehman@ida.org . Subject: Re: FRN 900426-A: DATA_ERROR . Cc: frteam@ajpo.sei.cmu.edu The first line of the previous message shgould have read: Well you (Norman) may imagine .... ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From dewar@acf2.NYU.EDU Mon Apr 30 12:31:18 1990 . To: NCOHEN@IBM.COM, dewar@acf2.NYU.EDU, lehman@ida.org . Subject: Re: FRN 900426-A: DATA_ERROR . Cc: frteam@ajpo.sei.cmu.edu "if we had any reason to think that the body used UNCHECKED_CONVERSION ..." >From the point of view of the implementation, what other possible interpretation could there be. As I said previously, it never occurred to me that reading junk data had any defined semantics. It is at least as bad as UC, and in practice probably worse. A good excercise in such cases is always to think about the sequence of machine instructions that would actually be emitted by a typical compiler runtime. When you see the phrase in the RM saying that checks are not necessary, a typical implementor would take that to mean that (a) the instructions to check for the value being reasonable can be omiitted (b) the read routine can be programmed assuming that the value IS reasonable! ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . From ploedere@tartan.com Tue May 8 22:39:15 1990 . To: lehman@ida.org . Cc: frteam@ajpo.sei.cmu.edu, lehman@ida.org . Subject: Re: FRN 900426-A: DATA_ERROR Apart from the other flaws in the test...I am wondering what is so hard about remapping a CONSTRAINT_ERROR into a DATA_ERROR within READ ? For uniformity's sake, you might advise the implementor about this possibility. And, yes, the test should be withdrawn and fixed. Erhard :::::::: END OF FILE :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: *****************************************************************************