Mirsad Todorovac wrote:
- Type initializers
I think that's touched in mir046*.pas
Almost. Move the `Value parm' to the type declaration.
Good, done.
OK.
Also we need some tests for the command-line options `--[no-]range-checking' (default on) and the compiler directives `{$[no-]range-checking}', and `{$R+}', `{$R-}'. (Only one case of range-failure suffices. The options/directives will be global, so we don't have to test every combination.)
Done: mir047[a-g].pas
{R+} and {R-} OTOH aren't global, right? - so I had to fix ExpectError function a bit. (Pls see attachment.)
Actually, the `AtExit' for the no-error cases can be omitted (slightly faster, since unit GPC is not needed), but I don't mind.
- I was looking the example of a variant record in iso10206.ps:
type subrange(l,u: integer) = l..u; a_subrange = subrange(expression1, expression2); variant_record (d: a_subrange) = record case d of 1: (f1: integer); 2: (f2: integer); end;
Is there a chance for an range error to be caught here, which isn't already trapped by schema subrange range in fsc35.pas?
I don't think so, but it's an interesting special case, so it might be worth providing an extra test case for it.
- BTW, (sorry if this has been discussed, I couldn't find anything)
wouldn't it be interesting to see an example when a range error could be "caught" by an exception-handler and recovered-from?
The `WriteLn ('OK')' in the tests is a kind of recovery. But if you mean recovery as going back to (or behind) the offending statement, you could do that using `goto' -- just be sure not to rely on too much (e.g., the state of a variable to which an out-of-range value was assigned). However, this mechanism is the same for all runtime errors, so you could just as well test it with some other kind of error.
Frank