Mail #9158

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: Mirsad Todorovac
Subject: range check test programs
Date: 6 Aug 2003, 19:13:52

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

File attachment

• rngv0.06.tar.gz (1 KB)

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

Replies

In reply to

Back to main page of archive

Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.

This page was created by Crystal 0.999 (Linux 2.4.27/i686).