Re: Unchecked_Deallocation and Constraint_Error

Re: Unchecked_Deallocation and Constraint_Error

[Christoph Grein]

> > ...
> >   Cmd : Integer_Array_Access := new Integer_Array(1..1);
> > ...
> >    Free(Cmd);
> >    Cmd(1) := 1;
> > ...
> >
> > Program should throw exception Constraint_Error, but it only
> > hangs at instruction Cmd(1) := 1; (but doesn't quit).
> 
> The Reference Manual is quite clear (section 13.11.2):
> 
> |                           _Erroneous Execution_
> |
> | 16. Evaluating a name that denotes a nonexistent object is erroneous.
> 
> You cannot expect that a Constraint_Error exception is raised in this
> case, unless your compiler documentation guarantees this.

That's correct, but 13.11.2(7) specifies that the value of Cmd is null after UD 
(I assume Free is an instantiation of UD), so a dereference Cmd(1) must raise 
CE, except 
when checks are suppressed.

Re: Unchecked_Deallocation and Constraint_Error

[Florian Weimer]

Christoph Grein <christoph.grein@eurocopter.com> writes:

> That's correct, but 13.11.2(7) specifies that the value of Cmd is
> null after UD (I assume Free is an instantiation of UD), so a
> dereference Cmd(1) must raise CE, except when checks are suppressed.

Oops, you are correct.  Maybe the OP is operating on a copy of the
access value, so that 13.11.2(7) does not matter.

Re: Unchecked_Deallocation and Constraint_Error

[Marin David Condic]

It is probably really important to know the platform, compiler, version and
compiler options enabled when discussing why an exception of this nature is
or is not raised. I could easily imagine a compiler optimizing away the
checks necessary for this exception in the abscence of options specifying
full Ada95 runtime checking.

I know, for example, that Gnat won't generate the checks that cause
Constraint_Error on integer range excptions unless you throw a switch to
enable it. Could this be a similar case?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87adu57ht6.fsf@deneb.enyo.de...
> Christoph Grein <christoph.grein@eurocopter.com> writes:
>
> > That's correct, but 13.11.2(7) specifies that the value of Cmd is
> > null after UD (I assume Free is an instantiation of UD), so a
> > dereference Cmd(1) must raise CE, except when checks are suppressed.
>
> Oops, you are correct.  Maybe the OP is operating on a copy of the
> access value, so that 13.11.2(7) does not matter.

Re: Unchecked_Deallocation and Constraint_Error

[Robert Dewar]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a4tmmj$asm$1@nh.pace.co.uk>...

> I know, for example, that Gnat won't generate the checks 
> that cause Constraint_Error on integer range excptions 
> unless you throw a switch to
> enable it. Could this be a similar case?

Well you may "know" this, but that does not make it true :-)

Range_Checks are indeed on by default in GNAT and always
have been. You are mixing this up with Overflow_Checks
which are not on by default (and if you don't know the
difference, consult the RM, these terms are defined there!)

It is of course true that the questioner might have made a
pilot error (for instance, one certainly would not expect
to get an exception using -gnatp on GNAT :-)

Re: Unchecked_Deallocation and Constraint_Error

[Marin David Condic]

O.K. Phraseology & punctuation being the issue, I can easily conceed that I
misused the term. :-) I'm by nature, disinclined to be a stickler for
accuracy - which is probably why I'm not a language lawyer.

The point remains that you need specific compiler settings in order to get
full compliance with the ARM & it doesn't happen by default with GNAT and
possibly other compilers. Not that this is a *bad* thing - just the way the
world is. Given the original question, I think its important to focus in on
the fact that any arbitrary Ada compiler out there isn't necessarily going
to behave as expected unless one checks out the documentation, etc., to be
sure it is properly configured and all appropriate options are taken.

The original poster might find a better answer to his question if we knew
the compiler brand & platform - someone might know what compiler settings to
go with to correct the problem.....

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0202201059.7794f5aa@posting.google.com...
>
> Well you may "know" this, but that does not make it true :-)
>
> Range_Checks are indeed on by default in GNAT and always
> have been. You are mixing this up with Overflow_Checks
> which are not on by default (and if you don't know the
> difference, consult the RM, these terms are defined there!)
>
> It is of course true that the questioner might have made a
> pilot error (for instance, one certainly would not expect
> to get an exception using -gnatp on GNAT :-)

Re: Unchecked_Deallocation and Constraint_Error

[Michal Nowikowski]

On Tue, 19 Feb 2002 15:15:44 +0100, Marin David Condic wrote:

> It is probably really important to know the platform, compiler, version
> and compiler options enabled when discussing why an exception of this
> nature is or is not raised. I could easily imagine a compiler optimizing
> away the checks necessary for this exception in the abscence of options
> specifying full Ada95 runtime checking.

I used Gnat 3.13p on Linux. I get this problem with all deallocated 
object. I have used only -gnatf flag. This problem apears in program
which I'm writting, but short test programs shows that this exception
is raised. It is possibile that exception raising have been turned off?

Godfryd

-- 
|  Michal Nowikowski <godfryd@zamek.gda.pl>
|  BOFH excuse #91: Mouse chewed through power cable

Unchecked_Deallocation and Constraint_Error

[Michal Nowikowski]

Hello

I've got some code like that:

...
  Cmd : Integer_Array_Access := new Integer_Array(1..1);
...
   Free(Cmd);
   Cmd(1) := 1;
...

Program should throw exception Constraint_Error, but it only
hangs at instruction Cmd(1) := 1; (but doesn't quit). Do you
know whats going on and how to push it to throw exception naturally.

Best Regards
Godfryd

-- 
|  Michal Nowikowski <godfryd@zamek.gda.pl>
|  BOFH excuse #190: Proprietary Information.

Re: Unchecked_Deallocation and Constraint_Error

[Florian Weimer]

Michal Nowikowski <godfryd@zamek.gda.pl> writes:

> I've got some code like that:
>
> ...
>   Cmd : Integer_Array_Access := new Integer_Array(1..1);
> ...
>    Free(Cmd);
>    Cmd(1) := 1;
> ...
>
> Program should throw exception Constraint_Error, but it only
> hangs at instruction Cmd(1) := 1; (but doesn't quit).

The Reference Manual is quite clear (section 13.11.2):

|                           _Erroneous Execution_
|
| 16. Evaluating a name that denotes a nonexistent object is erroneous.

You cannot expect that a Constraint_Error exception is raised in this
case, unless your compiler documentation guarantees this.

Re: Unchecked_Deallocation and Constraint_Error

[Jim Gleason]

Florian Weimer wrote:

> You cannot expect that a Constraint_Error exception is raised in this
> case, unless your compiler documentation guarantees this.

LRM 13.11.2(7) states that the value of the variable after Free is null.
This, combined with 4.1(13), implies that a Constraint_Error SHOULD be
raised.  I would contact your compiler vendor.  A conforming implementation
should raise a Constraint_Error by default in this instance.

Re: Unchecked_Deallocation and Constraint_Error

[Robert Dewar]

Florian Weimer <fw@deneb.enyo.de> wrote in message news:<87y9hp7kcl.fsf@deneb.enyo.de>...
> The Reference Manual is quite clear (section 13.11.2):
> 
> |                           _Erroneous Execution_
> |
> | 16. Evaluating a name that denotes a nonexistent object > is erroneous.
> 
> You cannot expect that a Constraint_Error exception is 
> raised in this case, unless your compiler documentation 
> guarantees this.

Apparently not clear enough, since you are seriously
misreading it :-)

Of course CE should be thrown in this case, and the quoted
section of the RM is entirely irrelevant (this section comes into play
if you have two access values and free
via one, and attempt a reference via the other).

The reported behavior is a clear bug and should be
reported to the vendor.