Mirsad Todorovac wrote:
On Thu, 31 Jul 2003, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
http://www.alu.hr/~mtodorov/rngv0.04.tar.gz/mir043[ceil][lu].pas403
BTW, I'd prefer it you send such files by email attachment (either privately or to the list, if anyone else cares at all). I usually terminate my internet connection after downloading my mail, and if I have to get a HTTP file, I have to connect again. Thanks.
Sorry to have wasted your resources, I haven't realized you do not have a permanent connection. I'm sending in attachment now.
(The link above wasn't actually a real link, but a scheme.)
I know, but `http://www.alu.hr/~mtodorov/rngv0.04.tar.gz' was 403.
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?
Yes.
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.
I think we have such a test. (I'd have to check -- if you feel urged, you can write (another?) one, but I think it's not really necessary.)
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. (!!!)
I think constants require compile-time constants, so forget about them. Types (`type Foo = Bar value Baz') should be relevant, though. (You might have to declare a variable of the initialized type in order to provoke the range-check error.)
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);
No. It will be fixed in the next release. (fjf909.pas)
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
These were for the 2nd parameter.
Still missing now:
- Val 3rd parameter
- Pack, Unpack more strictly
- Type initializers
- `asm' target (IA32 specific suffices)
BTW, some tests do "too much", but I'll leave it at that now. (Hope they'll always catch the right error.)
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.
I might. (But perhaps I'll make an alpha shortly after implementing range-checking, anyway.)
Frank