On Sat, 12 Jul 2003, Frank Heckenbach wrote:
[...]
Perhaps you've missed Francois' previous mail where he quoted the items I have thought of already (appended below). If you can think of more (which Francois didn't already write), fine, but first we need someone to write those tests.
Sure.
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 :-(:
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.
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?
(mir040a.pas is in attachment.)
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
The `FillChar' test (fsc20.pas) shouldn't (I think) work like this since it takes an untyped parameter. (Some people (ab)use it for strange purposes.) Instead, the 3rd parameter may also be an integer, so it's an error if it's < 0 or > Ord (MaxChar).
Done: mir042[ul].pas
I've found some more missing cases:
- `Return' (where the result type is a subrange and the `Return' value is out of range)
Done. mir0{24c[ul],25[ei][ul],26l[ul].pas
- `Pack', `Unpack' (the index parameter)
Done. mir03[56]*.pas
- `Include', `Exclude'
Done. mir028*.pas
- `Inc', `Dec'
Done. mir027*.pas
- 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
- `Val' (2nd and 3rd parameter)
Done 2nd parm. mir034[ab].pas
Q: What is the legal range for 3rd parm of Val?
- `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
- 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 `+' ./mir038ea.pas:29: incompatible type for argument 1 of `conformantArray' ./mir038ea.pas:11: routine declaration failed
{$gnu-pascal} program mir038ea; {slice array write, what Francois has done for Integer here is for subrange} uses GPC; type TGrayScale = (Black, Gray10, Gray20, Gray30, Gray40, Gray50, Gray60, Gray70, Gray80, Gray90, White); TMidTones = Gray30..Gray70; var v : array[1..100] of Integer; i,j : TGrayScale; procedure conformantArray(a: array[l..u : TMidTones] of Integer); begin end;
procedure ExpectError; begin if ExitCode = 0 then WriteLn ('failed') else begin WriteLn ('OK'); Halt (0) {!} end end;
begin AtExit(ExpectError); i:=Gray30; j:=White; {j > upper} conformantArray(v[i..j]); end.
- `New' with variant records (where the variant tag is of subrange type)
See the generated warning in test above.
- sets (e.g., assigning a set of a larger range to one of a smaller range where the former contains out of range elements)
Done. mir029*.pas
Conclusion:
1. variant record warning 2. Val's 3rd parameter 3. Possible bug with conformant arrays when bounds are of Char subrange, confirmed it occurs with enumerated subranges too 4. All tests WILL AND MUST give "failed" if you don't have range-checking compiler, with range-checking on, they should give OK
The latest result is at
http://www.alu.hr/~mtodorov/pascal/rngv0.03.tar.gz
There is significantly more of them now than in v0.02, and some bugs are fixed.
I think we're moving somewhere.
Have a nice day, Mirsad
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.
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.
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.)
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.
- `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.
- 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.
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.
- `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).
- 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.
Since I've made slight changes, please send me only new/updated files next time.
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.)
Frank
On the subject of range checking, another difference that Mac Pascals implemented was unrangechecked arrays where the lower and upper bound are both 0.
That is:
type UnboundArray = array[0..0] of Whatever;
disables the range check tests for array access.
Generally this is used for open arrays as parameters, and it pretty much just avoids having to define a specific maximum array size (which can also get in to trouble, such as:
type UnboundArray = array[0..kMaxInt] of Whatever;
which can have a size bigger than 4Gig if Whatever has any noticeable size, and which can cause problems (does GPC handle record/array sizes larger than 32 bits on 32 bit platforms?).
Anyway, I don't know that this is worth emulating even with --mac-pascal turned on, but I figured I'd mention it while I thought of it and while range checks were being discussed.
Enjoy, Peter.
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.
Actually, I was trusting what was written on http://www.gnu-pascal.de/gpc/h-support.html
Mirsad
On Wed, 30 Jul 2003, Peter N Lewis wrote:
On the subject of range checking, another difference that Mac Pascals implemented was unrangechecked arrays where the lower and upper bound are both 0.
That is:
type UnboundArray = array[0..0] of Whatever;
disables the range check tests for array access.
Generally this is used for open arrays as parameters, and it pretty much just avoids having to define a specific maximum array size (which can also get in to trouble, such as:
type UnboundArray = array[0..kMaxInt] of Whatever;
which can have a size bigger than 4Gig if Whatever has any noticeable size, and which can cause problems (does GPC handle record/array sizes larger than 32 bits on 32 bit platforms?).
Anyway, I don't know that this is worth emulating even with --mac-pascal turned on, but I figured I'd mention it while I thought of it and while range checks were being discussed.
(I'm sorry if this has been discussed in Dec/2002, I couldn't find in archives.)
Perhaps it's worth a spare attribute or two, such as
attribute(norange);
and
attribute(mustrange);
(the names are not obligatory part of suggestion).
They'd allow finer-grained range checking control than {R+} and {R-}, per object or per entity. Of course, if that's not too much trouble for Frank.
I hope it's not adding too much complexity to the compiler. In ideal case, every particular type of range check might be turned on/off independently. OTOH, you might consider it an overkill, as GNU Pascal is not used for programming Mars vehicles anyway (-;
I've read about some researches telling how most often errors are so called "of by one" errors, and IMHO is thus a vital part of chasing bugs out of the program, triggering an error exactly where it occurs, not segfaulting miles of code later.
Have a nice day, Mirsad
Peter N Lewis wrote:
On the subject of range checking, another difference that Mac Pascals implemented was unrangechecked arrays where the lower and upper bound are both 0.
That is:
stupid because
type UnboundArray = array[0..0] of Whatever;
is a perfectly valid Pascal array of size 1.
disables the range check tests for array access.
which is wrong if one actually declares a variable of this type (which the compiler doesn't prevent, I assume?).
I know this kludge from BP (though one has to disable range-checking explicitly). I prefer the following kludge:
type UnboundArray = array [1 .. MaxVarSize div SizeOf (Whatever)] of Whatever;
This "disables" range-checking for this type by making the range as big as possible. It also should prevent declaring a variable of this type for size reasons. The kludge also works in GPC, BTW, and might in Mac Pascals (with a suitable definition of MaxVarSize, of course).
Generally this is used for open arrays as parameters, and it pretty much just avoids having to define a specific maximum array size (which can also get in to trouble, such as:
type UnboundArray = array[0..kMaxInt] of Whatever;
which can have a size bigger than 4Gig if Whatever has any noticeable size, and which can cause problems (does GPC handle record/array sizes larger than 32 bits on 32 bit platforms?).
No (therefore the `div' above, same in BP with MaxVarSize = $fff0).
Frank
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
Mirsad Todorovac wrote:
Perhaps it's worth a spare attribute or two, such as
attribute(norange);
and
attribute(mustrange);
(the names are not obligatory part of suggestion).
They'd allow finer-grained range checking control than {R+} and {R-}, per object or per entity. Of course, if that's not too much trouble for Frank.
I'm not sure. In the ideal case, it would take "only" one flag for each ordinal type. (Those flags are a limited "resource" by the backend. Currently, we have some left, but we shouldn't waste them.)
I'm not sure if it's worth the effort, since we have a clean (conformant arrays, schemata) and a BP-compatible (MaxVarSize) alternative, and such an attribute also wouldn't be compatible to anything.
I hope it's not adding too much complexity to the compiler. In ideal case, every particular type of range check might be turned on/off independently.
Quite a bit of very tedious work ...
I've read about some researches telling how most often errors are so called "of by one" errors, and IMHO is thus a vital part of chasing bugs out of the program, triggering an error exactly where it occurs, not segfaulting miles of code later.
Yes, that's the basic idea of range-checking. Of course, for "emulated" variable-sized arrays (whether 0 or MaxVarSize), the compiler has no way to know the actual size, so we can forget about it. All other cases should be caught be range-checking in the future.
Frank
Mirsad Todorovac wrote:
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.
Actually, I was trusting what was written on http://www.gnu-pascal.de/gpc/h-support.html
Eike, did you change the text there? When I spoke about changing the text on the archive pages after the crash, I meant the archive pages themselves, not this link page (which probably wasn't too useful, since there are links to this archive from many places). Anyway, now that the archives are back (for quite some time), please restore the text.
BTW, what about the user permissions?
Frank
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.
Frank
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 used the opportunity to add few more tests.
BTW, I'm still not clear what should those "constant and type initializers" look like and so far I haven't been able to think of a situation where it isn't covered at compile-time.
Mirsad
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
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].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.
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
On Fri, 1 Aug 2003, Frank Heckenbach wrote:
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.)
Revisiting type initializers: was this what was meant?
program mir046cu; {type with integer initializer out of bounds, upper} uses GPC;
procedure localProc; type Foo = Char Value 'c'; var a: Foo Value 'f'; begin end;
procedure ExpectError; begin if ExitCode = 0 then WriteLn ('failed') else begin WriteLn ('OK'); Halt (0) {!} end end;
begin AtExit(ExpectError); localProc; end.
Thanks, Mirsad
Mirsad Todorovac wrote:
On Fri, 1 Aug 2003, Frank Heckenbach wrote:
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.)
Revisiting type initializers: was this what was meant?
Not exactly. These declarations would be valid. But a subrange type with a (non-constant) out-of-range initializer.
Frank
Mirsad Todorovac wrote:
- Val 3rd parameter
It's in mir034[cd].pas - I believe they should be in last attachment. I may have forgotten to mention.
They weren't there.
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. (-;
No, I don't mean that. Sometimes do you an additional assignment after the critical statment and in a few cases you do a loop where a single statement at the critical step would suffice.
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 ...
Yes, in most cases it's quite accurate. (Not always, but that's ok -- testing one off *always* could leave a small chance that the range checks miss "more" out-of-range cases. So I think in this regard the mixture is ok.)
Frank
On Mon, 4 Aug 2003, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
- Val 3rd parameter
It's in mir034[cd].pas - I believe they should be in last attachment. I may have forgotten to mention.
They weren't there.
Good Lord! You're right. They're attached now. (rngv0.05.tar.gz)
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. (-;
No, I don't mean that. Sometimes do you an additional assignment after the critical statment and in a few cases you do a loop where a single statement at the critical step would suffice.
Well, I was somewhat puzzled if the statement that isn't used by anything might be optimized out at -O3, I guess.
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 ...
Yes, in most cases it's quite accurate. (Not always, but that's ok -- testing one off *always* could leave a small chance that the range checks miss "more" out-of-range cases. So I think in this regard the mixture is ok.)
OK.
Not exactly. These declarations would be valid. But a subrange type with a (non-constant) out-of-range initializer.
mir046[ceil][lu].pas
Still missing now:
- Val 3rd parameter
mir034[cd].pas (finally)
- Pack, Unpack more strictly
Still TODO.
- Type initializers
I think that's touched in mir046*.pas
- `asm' target (IA32 specific suffices)
Still TODO.
I should have done more, but I'm sending this immediatelly, for the remaining subjects will require more study.
Mirsad
Mirsad Todorovac wrote:
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. (-;
No, I don't mean that. Sometimes do you an additional assignment after the critical statment and in a few cases you do a loop where a single statement at the critical step would suffice.
Well, I was somewhat puzzled if the statement that isn't used by anything might be optimized out at -O3, I guess.
At least with range-checks on, it won't because the backend sees the range-checking code as something with cannot be optimized away (in particular in the case where the check fails -- it might be able to remove a few compile-time-known non-failing checks, though).
- Type initializers
I think that's touched in mir046*.pas
Almost. Move the `Value parm' to the type declaration.
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.)
Frank
Frank Heckenbach wrote:
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.
GCC also defines --bounds-check, the gcc-3.3 docs read:
" -fbounds-check For front-ends that support it, generate additional code to check that indices used to access arrays are within the declared range. This is currently only supported by the Java and Fortran 77 front-ends, where this option defaults to true and false respectively. -ftrapv This option generates traps for signed overflow on addition, subtraction, multiplication operations."
The options/directives will be global, so we don't have to test every combination.)
This implies that $R+/$R- can not be used to set range checking off locally, e.g. for a block or a procedure ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
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.
GCC also defines --bounds-check, the gcc-3.3 docs read:
" -fbounds-check For front-ends that support it, generate additional code to check that indices used to access arrays are within the declared range. This is currently only supported by the Java and Fortran 77 front-ends, where this option defaults to true and false respectively.
That's too specific. (And I'm not convinced we should implement a compatibility option that checks only array bounds.)
-ftrapv This option generates traps for signed overflow on addition, subtraction, multiplication operations."
That's a wholly different story (and probably also too specific if it only applies to "signed" overflow -- whatever this is supposed to mean -- and to those 3 operations and misses, e.g. shifts).
The options/directives will be global, so we don't have to test every combination.)
This implies that $R+/$R- can not be used to set range checking off locally, e.g. for a block or a procedure ?
Yes, they can. I meant global WRT the different situations of range checks, not to the part of source code they apply to.
Frank
On Tue, 5 Aug 2003, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
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. (-;
No, I don't mean that. Sometimes do you an additional assignment after the critical statment and in a few cases you do a loop where a single statement at the critical step would suffice.
Well, I was somewhat puzzled if the statement that isn't used by anything might be optimized out at -O3, I guess.
At least with range-checks on, it won't because the backend sees the range-checking code as something with cannot be optimized away (in particular in the case where the check fails -- it might be able to remove a few compile-time-known non-failing checks, though).
- Type initializers
I think that's touched in mir046*.pas
Almost. Move the `Value parm' to the type declaration.
Good, done.
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.)
That leaves still TODO:
- [Un]Pack more strictly and - 'asm' target
2. 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?
3. 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?
Thank you, Mirsad
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
-
Adriaan van Os -
Frank Heckenbach -
Mirsad Todorovac -
Peter N Lewis