TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Christoph & Ursula Grein <[log in to unmask]>
Reply To:
Christoph & Ursula Grein <[log in to unmask]>
Date:
Sat, 1 Sep 2001 12:12:11 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (103 lines)
> > procedure Main2 is
> >
> >    type Color is (Red, Green);
> >
> >    procedure Initialize (P : in out Color) is
> >    begin
> >       P := Green;
> >    end;
> >
> >    Var : Color;
> >    Tar : Color range Red..Red;
> >    Car : Color range Green..Green;
> >
> > begin
> >
> >    Initialize(Var);  -- GNAT 3.13p Does not raise exception
> >    Initialize(Car);  -- GNAT 3.13p Raises Constraint_Error
> >    Initialize(Tar);  -- GNAT 3.13p Raises Constraint_Error
> >
> > end;
> >
> Testing revealed no exceptions with pass-by-reference parameters. I need to
>  understand when is this simply awful but unexceptional code, and when is it
>  prone to exceptions.  In particular, can the first call  potentially raise
>  exceptions on some other implementation?  RM 3.2.2(12) suggests why a
>  pass-by-copy parameter could raise an exception, but then why don't all
>  three calls raise Constraint_Error?

Var and the parameter P both have the same subtype, so no range checking is
necessary.

>  Are pass-by-reference parameters always
>  immune to exceptions under these conditions?

Yes, since there is no copying.

> > The second category of problems is failure to assign a value to an "out"
>  parameter.  This is certainly a problem if the caller should try to use the
>  result.  However, exceptions can still arise even if the parameter is not
>  used.  Consider another example:
> >
> > procedure Main is
> >
> >    type Color is (Red, Green);
> >
> >    procedure Is_Broken (P : out Color) is
> >    begin
> >       null;
> >    end;
> >
> >    Var : Color;
> >    Tar : Color range Red..Red;
> >    Car : Color range Green..Green;
> >
> > begin
> >
> >    Is_Broken(Var);  -- Does not raise exception
> >    Is_Broken(Tar);  -- Does not raise exception
> >    Is_Broken(Car);  -- Raises Constraint_Error
> >
> > end;
> >

The same reason as above. That Tar does not raise an exception looks like a
coincidence to me. P must have been allocated at a place with the matching
internal representation (0 in this case).

> > The obvious solution is to always assign a value to the parameter, but this
>  may not always be possible.  For example, we have generic containers with
>  methods that can return a component and a validity flag.  If a component can
>  not be returned, the container assigns nothing to the component parameter,
>  and sets the validity parameter appropriately.  Unfortunately, the
>  containers have no formal nil object in there specification, and therefor
>  cannot return a safe value.  Again, to change a generic spec. can have
>  significant ripple effect on other units.

If adding such a nil object is impossible, try the suppress pragmas. This should
solve the problem. (In any case, the clean and preferable solution would be the
nil object.)

> >
> Thanks in advance for your comments,
>
>         - John Harbaugh


                                 o     _      _          _
 --------- __o       __o      /\_    _ \\o   (_)\__/o   (_)
 ------- _`\<,_    _`\<,_    _>(_)  (_)/<_     \_| \    _|/' \/
 ------ (_)/ (_)  (_)/ (_)  (_)         (_)    (_)     (_)'  _\o_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mein Radunfall
My bike accident


Christoph Grein
Mitglied von Ada-Deutschland
Member of Ada Germany
http:/www.ada-deutschland.de

http://home.T-Online.de/home/Christ-Usch.Grein
eMail: [log in to unmask]

ATOM RSS1 RSS2