Rational Compiler Problem ??

Rational Compiler Problem ??

[Andrew R. McConnell]

Hi folks. Is there _anything_ wrong or non-portable with this code?

-------------------
with Text_IO;

procedure Bug_Test is

    type Text_Field ( The_Text_Size : Positive := 1 ) is
      record
        The_Text : String ( 1 .. The_Text_Size ) := ( others => ' ' ) ;
      end record ;

Size : Positive := 5 ;
My_Text_Field : Text_Field(Size);

begin
  Text_IO.Put_Line("Hello");
end Bug_Test;
--------------------


It compiles, links, and runs cleanly in my IBM/AIX environment as well
as in the DEC Ada environment.  However, when compiled on the
HP/Rational platform, warning messages(not errors) are generated:

 104:    type Text_Field ( The_Text_Size : Positive := 1 ) is
 105:      record
A ---------^
A:warning: RM Appendix F: storage needed for component exceeds implementation li
mit
 106:        The_Text             : String ( 1 .. The_Text_Size ) := 
A ----------------------------------^
A:warning: RM Appendix F: unconstrained record component size exceeds limit
 107:                                              ( others => ' ' ) ;



Is this a problem with the Rational compiler?  This code _will_ link,
but the executable fails miserably.  I don't have access to the
documentation as to known bugs, etc.

Also, is there any such thing as an "acceptable" warning from an Ada
compiler?  (I hope not - how else can I make fun of C-philes? ;-) )
-- 
Andrew McConnell             "Ford!" he said, "there's an infinite number of
Voice: (304) 594-9819      monkeys outside who want to talk to us about this 
FAX:   (304) 594-3951      script for 'Hamlet' they've worked out."
mcconnel@source.asset.com                                    -- Arthur Dent

Re: Rational Compiler Problem ??

[Kent Mitchell]

Andrew R. McConnell (mcconnel@source.asset.com) wrote:
: Hi folks. Is there _anything_ wrong or non-portable with this code?

: -------------------
: with Text_IO;

: procedure Bug_Test is

:     type Text_Field ( The_Text_Size : Positive := 1 ) is
:       record
:         The_Text : String ( 1 .. The_Text_Size ) := ( others => ' ' ) ;
:       end record ;

: Size : Positive := 5 ;
: My_Text_Field : Text_Field(Size);

: begin
:   Text_IO.Put_Line("Hello");
: end Bug_Test;
: --------------------


: It compiles, links, and runs cleanly in my IBM/AIX environment as well
: as in the DEC Ada environment.  However, when compiled on the
: HP/Rational platform, warning messages(not errors) are generated:

:  104:    type Text_Field ( The_Text_Size : Positive := 1 ) is
:  105:      record
: A ---------^
: A:warning: RM Appendix F: storage needed for component exceeds implementation li
: mit
:  106:        The_Text             : String ( 1 .. The_Text_Size ) := 
: A ----------------------------------^
: A:warning: RM Appendix F: unconstrained record component size exceeds limit
:  107:                                              ( others => ' ' ) ;



: Is this a problem with the Rational compiler?  This code _will_ link,
: but the executable fails miserably.  I don't have access to the
: documentation as to known bugs, etc.

Ahhhh yes. the ever popular descriminate record problem.

The first thing I'd like to address is the the statement that the executable
"fails miserably".  I don't know what you mean by this but the code *should*
link and execute.  I'd need to know more details about which Rational
compiler you were using to provide more precise information.  I tired this
on Rational Apex and it did execute.  I assume you are using some flavor of
VADS.  I'll check it out if you provide more info.

The second issue is why you get the warning in the first place, no this
is not a bug with the Rational compiler but rather an attempt to warn
you about the possible ramifications of the type declaration that you have
provided.  If addition to you given examples it would also be possible to
declare an additional varaible of type Text_Filed and not specify a size
(i.e. Foo: Text_Field; ).  Now by definition this varaible is unconstrained
and could be set to any size.  There are two schools of thought on the
implementation of this type of variable.  One (the one used by Rational)
is to allocate the maximum size for the type in question.  The other is to
not allocate space at all for the object until it is set and then do an
implicit dynamic allocation.  The first solution has the advantage that is
is static and dose not require any implicit dynamic allocation.  It does
(in some cases) fail because of the size of the allocation involved
(positive'last+4 bytes in this case).  The second implementation has the
advantage that you can actually write this type of declaration but it can
lead to fragmentation of the heap if you do a lot of resetting of the size
of the object on the fly.  In addition it uses dynamic allocation which is
forbidden in some embedded systems.  All this is within acceptable
implementation variations.

: Also, is there any such thing as an "acceptable" warning from an Ada
: compiler?  (I hope not - how else can I make fun of C-philes? ;-) )

There are many warning that can be issue by an Ada compiler though *most*
of then are real attempts to warn you that your program is *not* going to
execute.  For example, a compiler is not allowed to reject a program for
compilation even if it can figure out that it will just raise an exception
(i.e. you are violating range constraints at a static level).  These
kinds of errors are actually defined as runtime errors by the LRM.
However, most Ada compiler will issue warnings for this class of error.  I
don't know of any Ada compiler that issues "acceptable" warnings in the C
sense because most of thoses classes of errors are just that is Ada
*errors*.  For example, I assume you are referring to the kinds of warning
one gets from C compilers when one mixes integers and pointers.  This class
of operation is and error in Ada.  One could argue that it would be better
if the Rational compiler had issued the warning at the point where you create
an unconstrained variable that would actually *cause* the giant storage
allocation *but* it was decided that it was better to warn the supplier of
the type than the clients.

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

Re: Rational Compiler Problem ??

[Bob Duff]

In article <35ur1m$9n3@source.asset.com>,
Andrew R. McConnell <mcconnel@source.asset.com> wrote:
>Hi folks. Is there _anything_ wrong or non-portable with this code?
>
>-------------------
>with Text_IO;
>
>procedure Bug_Test is
>
>    type Text_Field ( The_Text_Size : Positive := 1 ) is
>      record
>        The_Text : String ( 1 .. The_Text_Size ) := ( others => ' ' ) ;
>      end record ;
>
>Size : Positive := 5 ;
>My_Text_Field : Text_Field(Size);
>
>begin
>  Text_IO.Put_Line("Hello");
>end Bug_Test;
>--------------------

The above code should work fine on all implementations.  However,
whenever you give a default for a discriminant, that means you're
allowed to declared uncontrained variables of the type (i.e. variables
where the discriminant can change on assignment).  It makes sense to
warn you about this -- if you don't intent to create unconstrained
variables, then you shouldn't give a default; if you do intend to create
unconstrained variables, then you had better declare a shorter range for
the discriminant, or else you will get Storage_Error, at least on some
implementations.

Ada is intended, at least in part, for real-time systems, where using
the heap without the user's permission is a no-no (user's permission
means the user wrote a "new").  So many compilers will allocate
unconstrained variables of the above type with the maximum possible
size, which in the above case, will raise Storage_Error.

Some compilers will allocate such unconstrained variables on the heap,
with the current size, and if the size changes, deallocate the old thing
and reallocate a new one, and so will not raise S_E unless you actually
try to create something big.  But counting on this is not portable, and
won't work properly in certain real-time situations anyway.

>It compiles, links, and runs cleanly in my IBM/AIX environment as well
>as in the DEC Ada environment.  However, when compiled on the
>HP/Rational platform, warning messages(not errors) are generated:
>
> 104:    type Text_Field ( The_Text_Size : Positive := 1 ) is
> 105:      record
>A ---------^
>A:warning: RM Appendix F: storage needed for component exceeds implementation li
>mit
> 106:        The_Text             : String ( 1 .. The_Text_Size ) := 
>A ----------------------------------^
>A:warning: RM Appendix F: unconstrained record component size exceeds limit
> 107:                                              ( others => ' ' ) ;
>
>
>
>Is this a problem with the Rational compiler?  This code _will_ link,
>but the executable fails miserably.  I don't have access to the
>documentation as to known bugs, etc.

The warning seems reasonable, but the program should still work.  You
did *not* create an unconstrained variable, so it should *not* try to
allocate a huge amount of storage.

>Also, is there any such thing as an "acceptable" warning from an Ada
>compiler?  (I hope not - how else can I make fun of C-philes? ;-) )

The RM has nothing to say about warnings -- it's entirely up to the
compiler.  Some compilers "cry wolf" with warnings that can be safely
ignored.  That's annoying.

But the above warning seems like a good one.  Just remove the default
expression, or else use a smaller range than Positive for the
The_Text_Size.

As for C, most of the "warnings" you get from a C compiler will be
"errors" in an Ada compiler.
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: Rational Compiler Problem ??

[Alan D Zimmerman, Loral RSA]

In article 9n3@source.asset.com, mcconnel@source.asset.com (Andrew R. McConnell) writes:
> HP/Rational platform, warning messages(not errors) are generated:
> 
>  104:    type Text_Field ( The_Text_Size : Positive := 1 ) is
>  105:      record
> A ---------^
> A:warning: RM Appendix F: storage needed for component exceeds implementation li
> mit
Isn't the problem here that the compiler will allocate a string of size postitive'size.
It looks like the HP won't allow you to create strings that big.  I think a more portable
way to accomplish this would be to create a type text_size that is constrained to be
the size allowable for strings (e.g. 1..256 or 1..512).

Just my $0.02 worth :->

Alan Zimmerman
Software Engineer
Loral Space & Range Systems

Views and opinions are my own.