On Fri, 1 Aug 2003, Frank Heckenbach wrote:
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].pas
403
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.
You're right: it came to me just after I've pressed "Send" that /pascal/ is missing between ~mtodorov/ and /rngv0.04.tar.gz
My error. Please accept apology.
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.
Good.
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)
Excellent.
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
It's in mir034[cd].pas - I believe they should be in last attachment. I may have forgotten to mention.
Pack, Unpack more strictly
Type initializers
`asm' target (IA32 specific suffices)
I recall you said Pack, Unpack have some additional possibilities. Type initializers are a news for me. But I think I'll manage.
BTW, some tests do "too much", but I'll leave it at that now. (Hope they'll always catch the right error.)
Well, so do I: but some things I've inherited some of it.
I hope you don't mean TGrayScale enumerated type, because I'm sort of fond of it. (-;
You could have noticed how I try to catch precisely "one off" errors in my last tests, so I hope they're improved by now ...
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.)
No harm done, I guess. As it fits you the best.
Mirsad