On Wed, 30 Jul 2003, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
Here is the point when I think I've done what I could. Let's go step by step with this list (I'm sorry if I'm repepating something that has been said already, but the list archive appears to be out :-(:
Perhaps a temporary server overload or something. They seem to be working fine.
Yes, sorry, the mail archive is working fine, thanks. I was confused by outdated not on the web page.
What's missing is a test where the formal discriminants are of a subrange type and the actual discriminants (in `New' or a variable declaration) are out of range.
This note was referring to `New' with schemata. I think that's still missing.
http://www.alu.hr/~mtodorov/rngv0.04.tar.gz/mir043%5Bceil%5D%5Blu%5D.pas
TEST mir040a.pas: gpc1: warnings being treated as errors ./mir040a.pas: In main program: ./mir040a.pas:34: warning: tag value must be a constant of ordinal type failed (I think it could be the problem in GPC, since the code is precisely the same, as with integer subrange bounds conformant arrays.)
Am I allowed to suppress this specific warning, is it possible to do suppress it, or have I done something wrong?
Ah, no. The tag must be constant according to EP, so this actually isn't a case for runtime range-checking, so we can forget about variant records here. (Variant records are special in this regard -- I suppose that's to simplify work for compilers that allocate memory based on the actual tag value.)
Then we drop mir040[ab].pas, I guess?
The case with constant seems to be already detected at compile time with my present compiler (20030507). If we need a WRONG test that would keep this verified, it's not a problem to fix that.
Initialization of types, variables and typed constants. (I.e., variables (or fields) or subrange type with an out-of-range initializer; must be locally, otherwise GPC won't accept non-constants initializers.)
Done. mir041[ceil][ul].pas
These are for variables. Please add a few (not all combinations) for constants and type intializers.
Err, I tried but I've got something illegal. I think I'll need an example or two on these. (!!!)
- `Pack', `Unpack' (the index parameter)
Done. mir03[56]*.pas
In fact, the ranges of the packed and unpacked array don't have to be the same. (I think they could even be completely different types such as integer vs. char etc., IIUC what EP says.) The index parameter refers to the unpacked array (for both routines), and the requirement is only that it can hold the number of elements the packed array has, starting from that index. So there can be cases where the array fits only partly etc.
Thank you for this explanation.
Doing this I bump more and more into "(Under construction.)" signs in manual. (-;
- 4th parameter of `BlockRead', `BlockWrite' (not obvious, but GPC allows a subrange here which may be too small for the actual result)
Done. mir039*.pas
I've changed the file name to `.dat' (the Makefile will remove those files in the clean targets). I'm adding a note about this in the test suite documentation.
Good. Please note that there's a Reset (myF) missing in v0.03 tarball (Fixed in v0.04 tarball) - alongside this extension modification.
Q: What is the legal range for 3rd parm of Val?
It gives 0 for success and the position of the first invalid character otherwise.
Done: mir034[cd].pas
Just curious, Val returned 2 and 17 in ec after these two tests respective. Is that OK?
Val ('invalid', k, ec); Val ('123456789012345invalid', k, ec);
- `and', `or', `xor', `shl', `shr' used as procedures, e.g., if a is of type 1 .. 10: a := 5; or (a, 8) (whereas normal use as operators will be covered by assignments or whatever is done with them)
Done. mir03[0-3]*.pas
I've slightly modified some of them, so the 2nd parameter is still in range, but the result is not.
I think I forgot to mention `not' (bitwise, procedure-like).
mir044[ab].pas
- Conformant arrays (i.e., where the index type in the conformant array in the formal parameter list is a subrange, and the actual parameter's range is too big -- check both bounds)
Integer subrange Done. Problems with Char and enumerated subranges. I can confirm that it gives me this error:
TEST mir038ea.pas: ./mir038ea.pas: In main program: ./mir038ea.pas:29: invalid operands to binary `+'
This should be fixed in the next release.
There is, however, an error (and the next GPC will give a better message). The formal array index is integer and the actual index is enum.
Yes, I've fixed it (mir038e?.pas).
This case is an indicator to me that as many as possible combinations (types, ranges etc.) ought to be tested, for otherwise this example is no difference with character lbound..ubound than the integer ones.
Since I've made slight changes, please send me only new/updated files next time.
OK, they're in v0.04 tarball mentioned above.
At my side they are of course all "failed". It would be reassuring if I get a confirmation that on range-checking compiler they all pass "OK".
I'll let you know if not when I'll have implemented range-checking. (Otherwise you'll see for yourself, since the tests will then be in the test suite, and a release will probably be done soon after.)
Since I'm doing tests, I would benefit from having builds pre-release. But only if this is not additional trouble to you.
Mirsad