Discriminated record question

Discriminated record question

[Mark Doherty]

Why does the following raise a constraint error on the declaration of
'B'.

I would not expect the declarations of 'A' or 'B' to raise a
constraint error.

If the compiler is right what, is the subtle difference between them
that allows 'A' not to raise the constraint error.

I am using Rational 3.2 compiler (PowerPC and Sun Solaris)



procedure Test is
    type A_Type (Text_Size : Natural := 0) is
       record
            Text : String (1 .. 0);
        end record;
    A : A_Type;

    type B_Type (Text_Size : Natural := 0) is
        record
            Text : String (1 .. Text_Size);
        end record;

    B : B_Type;  

begin
    null;
end Test;

Re: Discriminated record question

[Emmanuel Briot]

Mark.Doherty@uk.thalesgroup.com (Mark Doherty) writes:

> Why does the following raise a constraint error on the declaration of
> 'B'.
> 
> procedure Test is
>     type A_Type (Text_Size : Natural := 0) is
>        record
>             Text : String (1 .. 0);
>         end record;
>     A : A_Type;
> 
>     type B_Type (Text_Size : Natural := 0) is
>         record
>             Text : String (1 .. Text_Size);
>         end record;
> 
>     B : B_Type;  
> 
> begin
>     null;
> end Test;



Because when you specify a default value for the discriminant, the compiler
must allocate the maximum possible size (in that case Natural'Last), so you are
trying to declare a huge variable, which raises CE. I thought it would have
raised Storage_Error, but it might be compiler-dependent


Compiling the code above with GNAT gives a proper warning

gcc -c t8.adb
t8.adb:10:33: warning: creation of object of this type may raise Storage_Error
t8.adb:13:05: warning: Storage_Error will be raised at run-time
gnatbind -x t8.ali
gnatlink t8.ali

Re: Discriminated record question

[Grein, Christoph]

> From: Mark.Doherty@uk.thalesgroup.com (Mark Doherty)
> 
> Why does the following raise a constraint error on the declaration of
> 'B'.
> 
> procedure Test is
>     type A_Type (Text_Size : Natural := 0) is
>        record
>             Text : String (1 .. 0);
>         end record;
>     A : A_Type;

Text component is always empty here, whichever Text_Size you use, so all objects 
have the same (small) size.

> 
>     type B_Type (Text_Size : Natural := 0) is
>         record
>             Text : String (1 .. Text_Size);
>         end record;
> 
>     B : B_Type;  

I presume, Storage_Error is raised, not Constraint_Error as you claim.
Here Text component depends on Text_Size. You define an unconstrained object, so 
the discriminant can vary, therefore the compiler has to allocate the maximum 
size, which is Natural'Last - quite big I'd say.
(A different model could be implemented by implicitly allocating on the heap as 
much storage as is currently needed. But this model is rarely used - is it 
currently used at all by some compiler?)

So the difference is not so subtle...

Re: Discriminated record question

[Randy Brukardt]

Grein, Christoph wrote in message ...
>(A different model could be implemented by implicitly allocating on the
heap as
>much storage as is currently needed. But this model is rarely used - is
it
>currently used at all by some compiler?)

Janus/Ada does that (in both Ada 83 and Ada 95). I used to think that
that was the only reasonable model, but it is clear that the implicit
heap use is a bad thing in certain environments. (Of course, that can be
avoided by simply not declaring such a thing...)

           Randy Brukardt

Re: Discriminated record question

[Robert Dewar]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<udga38i7bj1g89@corp.supernews.com>...
> Janus/Ada does that (in both Ada 83 and Ada 95). I used 
> to think that that was the only reasonable model, but it 
> is clear that the implicit heap use is a bad thing in 
> certain environments.

Alsys used to do this as well in Ada 83. Did anyone get
it quite right? Alsys did not allow such beasts to be
nested in full generality, since this leads to complex
non-contiguous representations. 

At least one other Ada 83 compiler trying this (Janus?)
had storage leaks, and was so nice as to warn you that
declaring the type would cause a storage leak.

(it is non-trivial to avoid storage leaks, if you allow
these implicit heap pointers to nest).

It is definitely a bad idea for a compiler. If you want
pointers and dynamic allocation, write it that way. As far
as I am concerned, for a language at the level of Ada, it
is a bad idea in *all* cases to do implicit heap allocations for a
type declaration of this kind.

Re: Discriminated record question

[Randy Brukardt]

Robert Dewar wrote in message
<5ee5b646.0205081852.4e2c20dc@posting.google.com>...
>"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:<udga38i7bj1g89@corp.supernews.com>...
>> Janus/Ada does that (in both Ada 83 and Ada 95). I used
>> to think that that was the only reasonable model, but it
>> is clear that the implicit heap use is a bad thing in
>> certain environments.
>
>Alsys used to do this as well in Ada 83. Did anyone get
>it quite right? Alsys did not allow such beasts to be
>nested in full generality, since this leads to complex
>non-contiguous representations.
>
>At least one other Ada 83 compiler trying this (Janus?)
>had storage leaks, and was so nice as to warn you that
>declaring the type would cause a storage leak.
>
>(it is non-trivial to avoid storage leaks, if you allow
>these implicit heap pointers to nest).


Right, Janus/Ada 83 had significant storage leaks in a few cases. The
primary problem was that the code at runtime did not know which heap the
implicit data was allocated from, so it couldn't know the correct way to
deallocate it.

This is solved (I think) in Ada 95 with storage pools. Since every
object has an associated storage pool (usually its implicit) anyway, and
the thunks have to pass them around anyway, the deallocations can be
done safely. (Tuck as recently convinced me that the storage pool
implementation is wrong for nested scopes, but that's unrelated to the
deallocation problem.)

We still give the non-contiguous type warning, though, because it says
that taking 'Address on the object may not be a good idea, etc.

>It is definitely a bad idea for a compiler. If you want pointers and
dynamic allocation,
>write it that way.

The job of a compiler is to make programming as easy as possible for a
given language. Putting arbitrary limits on a language feature doesn't
meet that goal IMHO.

>As far as I am concerned, for a language at the level of Ada, it is a
>bad idea in *all* cases to do implicit heap allocations for a type
declaration of this kind.

You may be right, but then I would argue that the language is
incorrectly designed. Because it suggests that you can create an object
without determining the size until runtime, but that is not really true.
(Not that I have a better idea for the language.) The current situation
requires an arbitrary maximum size to be determined ahead of time, and
incorrectly choosing that size breaks the portability of your code.

            Randy.

Re: Discriminated record question

[Mark Doherty]

> I presume, Storage_Error is raised, not Constraint_Error as you claim.

It raises a Constraint_Error, albeit the debugger reports an
'Overflow_Error' first! The compiler would have been more helpful if a
Storage_Error was raised.

Does the compiler have the freedom to raise it as a Constraint_Error?

Mark Doherty

Re: Discriminated record question

[Robert Dewar]

Mark.Doherty@uk.thalesgroup.com (Mark Doherty) wrote in message news:<2d87db3f.0205080210.34726bf3@posting.google.com>...

> Does the compiler have the freedom to raise it as a 
> Constraint_Error?

Highly dubious if you ask me. Report it as a bug.

Note that GNAT is so kind as to give you a warning if
you declare a type like this:

     1. package q is
     2.    type x (a : natural := 0) is record
     3.       s : string (1 .. a);
                               |
        >>> warning: creation of object of this 
            type may raise Storage_Error

     4.    end record;
     5.
     6.    ss : x;
           |
        >>> warning: Storage_Error will be raised at 
            at run-time

     7. end;

And sure enough, if you run this program, Storage_Error
will be raised. I really think raising Constraint_Error
is very dubious here. What is likely going on is that
the compiler is getting an overflow trying to compute
the maximum size of the object. As I said earlier, I 
would report it as a bug.

The warnings in GNAT are quite useful (checkout the -gnatw
flag for turning them on, at the very least -gnatwu should
be used pretty much all the time, the only reason it is not
the default is that making it the default would require the
modification of literally hundreds of tests in our test
suite :-)

Robert Dewar
Ada Core Technologies

Re: Discriminated record question

[Mark Doherty]

> 
> > Does the compiler have the freedom to raise it as a 
> > Constraint_Error?
> 
> Highly dubious if you ask me. Report it as a bug.
> 

Rational responce was ...

It's confirmed that Constraint_Error is raised due to a limit being
exceeded. Specifically, the size of an object of type B_Type (see below)
cannot be represented in (signed) 32 bits.

      type B_Type (Text_Size : Natural := 0) is
          record
              Text : String (1 .. Text_Size);
          end record;

This is covered by RM95 section 1.1.3:

   2 � Translate and correctly execute legal programs written in
       Ada, provided that they are not so large as to exceed the
       capacity of the implementation;

   3 � Identify all programs or program units that are so large as
       to exceed the capacity of the implementation (or raise an
       appropriate exception at run time);

   3.a Implementation defined:  Capacity limitations of the
       implementation.

A key term is "appropriate exception" and, clearly, the Apex compiler has
chosen to report implementation capacity overflow with a Constraint_Error.

I note that section 11.1 (6) states:

   The execution of any construct raises Storage_Error if there is
   insufficient storage for that execution.

Thus it might be argued that the RM95 is inconsistent, or should better
define "appropriate exception", although I prefer to leave such discussion
to greater minds than mine. Whatever, the Apex compiler is consistent with
the language specification and therefore correct.

...

Seems like a weak justifcation to me!

Re: Discriminated record question

[Jeffrey Carter]

Mark Doherty wrote:
> 
> > > Does the compiler have the freedom to raise it as a
> > > Constraint_Error?
> >
> > Highly dubious if you ask me. Report it as a bug.
> >
> 
> Rational responce was ...
> 

[Justification deleted.]

> 
> Seems like a weak justifcation to me!

This is a case of the compiler being "correct but irritating". This is
related to compilers that are "correct but useless". In the latter case,
saying "Thank you. Your compiler is correct, but is unsuitable for our
needs. We are therefore evaluating other compilers for our project."
generally gets the vendor to sing a different tune. If you can honestly
say this to your vendor you may suddenly find yourself possessed of an
update that raises Storage_Error. But since this is only irritating, not
useless, it may not be worth the effort.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail

Re: Discriminated record question

[Grein, Christoph]

From: Jeffrey Carter <jrcarter@acm.org>
> This is a case of the compiler being "correct but irritating". This is
> related to compilers that are "correct but useless". In the latter case,
> saying "Thank you. Your compiler is correct, but is unsuitable for our
> needs. We are therefore evaluating other compilers for our project."
> generally gets the vendor to sing a different tune. If you can honestly
> say this to your vendor you may suddenly find yourself possessed of an
> update that raises Storage_Error. But since this is only irritating, not
> useless, it may not be worth the effort.

I very much like the Rational Apex system, but sometimes Rational people have the 
attitude of saying: "We know how to do it correctly, you blockhead..."