bertrand@cui.UUCP (IBRAHIM Bertrand) (10/11/88)
In the following sample code, I've been very surprised not to be warned by the
compiler that the initial value for k was out of range:
procedure bug is
type T is range 0..255;
k: constant T := 16#FFE1#;
begin
null;
end bug;
Even at execution time, no exception was raised. I thought that at least at
elaboration time I would get a numeric_error but it compiled and ran without
any problem. It is only if I try to compare k to another object of type T that
I get the numeric_error exception raised.
Is it normal behaviour or is it a bug in my VADS 5.5 compiler (the SUN
implementation) ?
Thank you for your replies,
Bertrand Ibrahim.
to BITNET to EAN
from
BITNET IBRAHIM@CGEUGE51.BITNET bertrand%cui.unige.ch@CERNVAX
ARPA IBRAHIM%CGEUGE51.BITNET@CUNYVM.CUNY.EDU bertrand%cui.unige.ch@ubc.csnet
UUCP cernvax!cui!bertrand.uucp
UUCP mcvax!cernvax!cui!bertrand.uucp
UUCP cui!bertrand@cernvax.UUCP
EAN bertrand@cui.unige.chfirth@sei.cmu.edu (Robert Firth) (10/13/88)
In article <243@cui.UUCP> bertrand@cui.UUCP (IBRAHIM Bertrand) writes: >In the following sample code, I've been very surprised not to be warned by the >compiler that the initial value for k was out of range: procedure bug is type T is range 0..255; k: constant T := 16#FFE1#; begin null; end bug; >Even at execution time, no exception was raised. Since the constant K is never subsequently used, the compiler has probably optimised your code and deleted both K and the initial assignment to it. That is legitimate [RM 11.6 (7)], but I confess I'd rather have had a compile-time warning. [The person who thought up that rule about having to add at least as much matter as you quote was a BLOODY MORON ]
fred@cs.utexas.edu (Fred Hosch) (10/14/88)
In article <7324@aw.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes: > Since the constant K is never subsequently used, the compiler > has probably optimised your code and deleted both K and the > initial assignment to it. That is legitimate [RM 11.6 (7)], > but I confess I'd rather have had a compile-time warning. > It's not clear to me that LRM 11.6(7) permits the compiler to optimize away the declaration elaboration. If K were a variable subsequently assigned, the "predefined operation" of assignment "need not be invoked." I think a CONSTRAINT_ERROR or NUMERIC_ERROR is required to be raised in this case? ---fred hosch fred@cs.utexas.edu
brucej@hcx9.SSD.HARRIS.COM (10/15/88)
> In the following sample code, I've been very surprised not to be warned by the > compiler that the initial value for k was out of range: > procedure bug is > type T is range 0..255; > k: constant T := 16#FFE1#; > begin > null; > end bug; The Verdix compiler typically does not elaborate static scalar constants. The declaration in question merely inserts the constant `k' into the compiler's symbol table. However, subsequent uses of the constant `k' will be constraint checked against type `T'. In this example there are no uses of `k'. The new (1.10) version of the validation suite contains several tests that enforce the requirement that constraint checks be performed on constant declarations. It's a good bet that this minor bug will be fixed when Verdix validates VADS to 1.10. Disclaimer: I do not work for Verdix, but for a computer vendor that is the proud owner of a VADS source license. And yes, the 1.10 suite is a real pain.... ---------- Bruce Jones, brucej@hcx1.harris.com Harris Computers, Fort Lauderdale, FL