f



Warning: Storage error

   type My_String (Length: Integer := 0) is 
      record
         Str: String(1..Length);
      end record;
   
warning: creation of "My_String" object may raise Storage_Error

Why this warning?

-- 
Victor Porton - http://portonvictor.org
0
Victor
8/9/2014 3:20:57 PM
comp.lang.ada 8774 articles. 2 followers. Post Follow

6 Replies
3870 Views

Similar Articles

[PageSpeed] 10

Using n normally defined integer with the bounds set to - 2GB .. 2GB, 
this type of unbound record size can range from 0 to 2GB.


All though today, most systems have 8 to 64 GB of main memory and up 
to 256 TB ( 2 ** 64 ) of virtual storage the Ada compiler does not 
know at compile time, the total run-time system memory or how much 
memory may be allocated to your program.  To correct this add a 
discriminant type or subtype

  --  Same size as just using "Integer' but compiler does not 
  --  generate the storage warnings 

  subtype D_Integer is Integer range 0 .. Integer ' Last ;

  type My_String ( Length : D_Integer := 0 ) is record
                                                     Str: String ( 1 .. Length ) ;
                                                   end record ;


You could say that GNAT is being overly touchy on some standard 
statements when using predefined types such as "Integer" or types 
that could cause a problem.


In <ls5e8r$373$1@speranza.aioe.org>, Victor Porton <porton@narod.ru> writes:
>   type My_String (Length: Integer := 0) is 
>      record
>         Str: String(1..Length);
>      end record;
>   
>warning: creation of "My_String" object may raise Storage_Error
>
>Why this warning?
>
>-- 
>Victor Porton - http://portonvictor.org

0
anon
8/9/2014 4:07:09 PM
On 08/09/2014 08:20 AM, Victor Porton wrote:
>     type My_String (Length: Integer := 0) is
>        record
>           Str: String(1..Length);
>        end record;
>
> warning: creation of "My_String" object may raise Storage_Error
>
> Why this warning?

There are 2 ways to implement such a type. One allocates just as much space as 
the current value (plus some small fixed overhead); the other allocates enough 
space for the largest value.

Some argue that Ichbiah intended the former, and there is at least one compiler 
that does it that way. It appears that you're using a compiler that uses the 
latter, and every such object will take at least Integer'Last bytes.

It also appears that you're attempting to reinvent Ada.Strings.Bounded.

-- 
Jeff Carter
"Insufficient laughter--that's grounds for divorce."
Play It Again, Sam
126
0
Jeffrey
8/9/2014 4:08:54 PM
On Sat, 09 Aug 2014 18:20:57 +0300, Victor Porton wrote:

>    type My_String (Length: Integer := 0) is 
>       record
>          Str: String(1..Length);
>       end record;
>    
> warning: creation of "My_String" object may raise Storage_Error
> 
> Why this warning?

Because you provided a default value.

It should have been:

   type My_String (Length: Natural) is record
      Str: String (1..Length);
   end record;

Or in the case of a varying length string with an upper bound:

   type My_String Size: Natural) is record
      Length : Natural := 0;
      Str: String (1..Size);
   end record;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
Dmitry
8/9/2014 4:21:01 PM
On Sat, 09 Aug 2014 09:08:54 -0700, Jeffrey Carter wrote:

> It also appears that you're attempting to reinvent Ada.Strings.Bounded.

A more frequent use case is a constant string allocated and initialized
once.

Ada.Strings.Bounded is practically unusable. Unbounded_String offers no
advantage over custom type because it requires explicit conversion to
String, and is suspicious for allocating more memory in advance than
actually required. RM is silent about the memory usage strategy.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
Dmitry
8/9/2014 4:26:23 PM
On 08/09/2014 09:26 AM, Dmitry A. Kazakov wrote:
>
> Ada.Strings.Bounded is practically unusable. Unbounded_String offers no
> advantage over custom type because it requires explicit conversion to
> String, and is suspicious for allocating more memory in advance than
> actually required. RM is silent about the memory usage strategy.

I agree that Ada.Strings.Bounded has a poor interface. I rarely use it. But when 
I do need bounded strings, I find the advantages of reuse usually outweight the 
disadvantages of the poor interface.

Using the standard library has the advantages of being more likely to be 
correct, requiring less development effort, and being easier for future readers 
to understand.

If you're worried about the implementation of an abstraction in the standard 
library in absence of any evidence that it is responsible for being unable to 
meet your requirements then you probably shouldn't be using Ada. Ada (and 
software engineering) is largely about abstraction and not worrying about 
implementations unless one has to.

-- 
Jeff Carter
"Insufficient laughter--that's grounds for divorce."
Play It Again, Sam
126
0
Jeffrey
8/9/2014 4:46:35 PM
On Sat, 09 Aug 2014 09:46:35 -0700, Jeffrey Carter wrote:

> Using the standard library has the advantages of being more likely to be 
> correct, requiring less development effort, and being easier for future readers 
> to understand.

Provided the library is used properly. Unbounded_String is not intended for
keeping constant strings. Or, considering another example of its frequent
*misuse*, for having String out-parameters.
 
> If you're worried about the implementation of an abstraction in the standard 
> library in absence of any evidence that it is responsible for being unable to 
> meet your requirements then you probably shouldn't be using Ada. Ada (and 
> software engineering) is largely about abstraction and not worrying about 
> implementations unless one has to.

I am worried about using wrong abstractions, which is poor engineering.
Unbounded_String is firstly poorly designed (should have been a type
related to String) and secondly is designed for a different purpose
(Strings of varying length).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
Dmitry
8/9/2014 4:57:27 PM
Reply: