What should this do?

What should this do?

[David T. Lindsley]

I have a question about dynamic strings.  I was looking at a package
on simtel20 that did the following:

             subtype INDEX is natural range 0..100;
             type DYN_STRING (SIZE : INDEX := 0) is private; 

--           private
--                 type DYN_STRING (size : index := 0) is
--                    record
--                        DATA : string (1..size);
--                    end record;

the second declaration had a note to the effect of "uncomment and use
this if you've got a VALIDATED compiler".

Now as far as I can tell, during elaboration, a declaration of the form

	S : DYN_STRING;

will result in the attempt to allocate an array constrained to (1..0),
which should raise an exception.  At least, that's what it does under
VAX Ada, but not on Verdix.  (Both generate warnings.)

It seems to me this has to be a bug in one of the compilers.  My question
is: whose?  Should this, or should it not, raise an exception?  (The
LRM references weren't any help.)

-- 
Dave Lindsley	#24601#			OPINIONS.  MINE.  (Nobody tells me
dlindsle@blackbird.afit.af.mil		  anything anyway, so I can't possibly 
    ?? lamroN eb yhW ??			  be anybody's mouthpiece...)

Re: What should this do?

[Howard Turner]

	dlindsle@afit.af.mil (David T. Lindsley) writes:
	I have a question about dynamic strings.  I was looking at a package
	on simtel20 that did the following:

	             subtype INDEX is natural range 0..100;
	             type DYN_STRING (SIZE : INDEX := 0) is private; 
	
	--           private
	--                 type DYN_STRING (size : index := 0) is
	--                    record
	--                        DATA : string (1..size);
	--                    end record;

	the second declaration had a note to the effect of "uncomment and use
	this if you've got a VALIDATED compiler".

	Now as far as I can tell, during elaboration, a declaration of the form

		S : DYN_STRING;

	will result in the attempt to allocate an array constrained to (1..0),
	which should raise an exception.  At least, that's what it does under
	VAX Ada, but not on Verdix.  (Both generate warnings.)

	It seems to me this has to be a bug in one of the compilers.  My question
	is: whose?  Should this, or should it not, raise an exception?  (The
	LRM references weren't any help.)


Ahemm...
While working on a recent project, I ran into much the same problem.
One of the persons involved (Bob Smith, smith@prc.unisys.com) found
the following and sent it to me.  Bob set me right.  Thanks Bob.  


	Bob Smith (quite a while ago) writes:
	...
	You might try reading LRM 3.6.1 paragraph 4:

	  If any of the discrete ranges defines a null range, any array thus 
	  constrained is a null array, having no components.

	Then take a look at 3.5 paragraph 3:
	
	  The range L .. R specifies the values from L to R inclusive if the 
	  relation L <= R is true. . . .  A null range is a range for which
	  the relation R < L is TRUE; no value belongs to a null range.
	...


While it does not explicitly mention strings, remember that the type 
string is defined as an array of characters.

Hopes this helps

Howard Turner
SAIC
619.458.2654
howard@esosun.css.gov

Re: What should this do?

[Jim Showalter]

dlindsle@afit.af.mil (David T. Lindsley) writes:

>I have a question about dynamic strings.  I was looking at a package
>on simtel20 that did the following:

>             subtype INDEX is natural range 0..100;
>             type DYN_STRING (SIZE : INDEX := 0) is private; 

>--           private
>--                 type DYN_STRING (size : index := 0) is
>--                    record
>--                        DATA : string (1..size);
>--                    end record;

>the second declaration had a note to the effect of "uncomment and use
>this if you've got a VALIDATED compiler".

>Now as far as I can tell, during elaboration, a declaration of the form

>	S : DYN_STRING;

>will result in the attempt to allocate an array constrained to (1..0),
>which should raise an exception.  At least, that's what it does under
>VAX Ada, but not on Verdix.  (Both generate warnings.)

No. If you declare S of type Dyn_String without specifying a value
for the Size, what you get is a "mutable record". What this means is
that you can come along later and assign a Dyn_String of any size to
it, and it will work. The reason is that the default size of zero
is NOT a discriminant, and so does not constrain the Data string to
be of any particular size. A nifty compiler could play all sorts of
games with mutable records to make them grow or shrink dynamically.
As it is, a typical compiler simply allocates as much space as COULD
be needed, and lets it go at that. In your example, this means 100
bytes or so of storage is allocated, regardless of whether you ultimately
assign a two character string to S or a 73 character string to S.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: What should this do?

[rharwood]

In article <1991Jun28.193513.14271@afit.af.mil>, dlindsle@afit.af.mil (David T.
Lindsley) writes:

>   [code example deleted for brevity... see same code below]
> will result in the attempt to allocate an array constrained to (1..0),
> which should raise an exception.  At least, that's what it does under
> VAX Ada, but not on Verdix.  (Both generate warnings.)

I compiled the following code on the VAX Ada compiler, ACS-LINKed it, and ran
it, all without error:
================== Code Startes Here ================
procedure test_100 is

  -- This is your definition package:
  package his_definitions is
             subtype INDEX is natural range 0..100;
             type DYN_STRING (SIZE : INDEX := 0) is private; 

           private
                 type DYN_STRING (size : index := 0) is
                    record
                        DATA : string (1..size);
                    end record;
  end his_definitions;
  use his_definitions;

  -- Your declaration here:
  S : DYN_STRING;
begin
    null;
end test_100;

Re: What should this do?

[Michael Feldman]

In article <1991Jun29.003159.20278@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>
>No. If you declare S of type Dyn_String without specifying a value
>for the Size, what you get is a "mutable record". What this means is
>that you can come along later and assign a Dyn_String of any size to
>it, and it will work. The reason is that the default size of zero
>is NOT a discriminant, and so does not constrain the Data string to
>be of any particular size. A nifty compiler could play all sorts of
>games with mutable records to make them grow or shrink dynamically.
>As it is, a typical compiler simply allocates as much space as COULD
>be needed, and lets it go at that. In your example, this means 100
>bytes or so of storage is allocated, regardless of whether you ultimately
>assign a two character string to S or a 73 character string to S.

Hmmm. This is not quite correct, Jim, regarding space allocation. For
example, Meridian allocates only a header block (dope vector, whatever)
and acquires space dynamically when needed. TeleSoft allocates the maximum,
which means that if the revord were declared as

   record (length: positive := whatever)
     stuff: string(1..length)
   end record;

the runtime system would try to acquire positive'last bytes. Big trouble.
On the other hand, allocating the maximum means that no reallocation
ever has to be done for the life of the object.

Moral: use the subtype system to keep the max length to a value that's
realistic in your application.

I was told once (but can't confirm) that Alsys uses a _linked_ allocation,
starting out with a blocksize equal to the default value and getting more
blocks as needed. Can anyone confirm this?

The point of my writing this is that implementing a powerful structure
often involves classical time/space tradeoffs: Meridian will use time
to save space (by always reallocating); TeleSoft will use space to save
time. Alsys is in between somewhere. The wise designer will understand
this and use the best structures for the job, in this case by choosing
a range for the discriminant that makes sense. This is one of the
portability gotchas in using any powerful structure; the careless
designer will probably get burned the worst.

BTW: I haven't seen a compiler manual yet that didn't lay out the details
of their data structures, just in case you're curious.

Mike

Re: What should this do?

[Jim Showalter]

>>A nifty compiler could play all sorts of
>>games with mutable records to make them grow or shrink dynamically.
>>As it is, a typical compiler simply allocates as much space as COULD
              ^^^^^^^
>>be needed, and lets it go at that.

>Hmmm. This is not quite correct, Jim, regarding space allocation. For
>example,

[several counter-examples of compilers that do a nifty job of storage
 management for mutable records deleted]

I'm probably suffering from obsolete data. Early compilers were notorious
for using the largest size a mutable record could be in all cases. It
looks as if the definition of "typical" compiler has changed for the better,
and I've been buried so deep in the specifics of Rational's products for
the past four years that I am out of touch with what the rest of the market
has been up to.

Gotta get out more...
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: What should this do?

[CBW Consulting]

There is nothing wrong with declaring an array to have a null range
(lower bound > upper bound) and this should not raise an exception on
any validated compiler.

You will however get an exception if you try to access a null array.
Now since the dynamic string type is declared as a private type, the
package that declares the private type should have all the operations
you need to manipulate strings.  I have used dynamic strings of this
type on several different compiler implementations without error.

Chuck Williams
CBW Consulting

Re: What should this do?

[voder!wlbr!lonex.radc.af.mil!blackbird.afit.af.mil!dlindsle]

rharwood@east.pima.edu writes:

>In article <1991Jun28.193513.14271@afit.af.mil>, dlindsle@afit.af.mil (David T
.
>Lindsley) writes:


>procedure test_100 is

>             subtype INDEX is natural range 0..100;
>             type DYN_STRING (SIZE : INDEX := 0) is private; 

>           private
>                 type DYN_STRING (size : index := 0) is
>                    record
>                        DATA : string (1..size);
>                    end record;

And this version does compile, even here.  Sorry about that, folks.  Our
AC is broken (it's 85F/30C-plus in here), and I'd been messing with that
package all day.
What I couldn't get to compile/run was:


  subtype Index is natural; -- range 0..100;
  type Dyn_String (Size : Index := 0) is record
    Data : string (1..Size);
  end record;

  S: Dyn_String;


But this still leaves me with a question.  Why does this work with a
constrained subtype, but not with an unconstrained one?  Either results
in the elaboration of a null array -- why is this a problem with an
unconstrained subtype?  (Especially since NATURAL is a discrete (sub)type
anyway...

-- 
Dave Lindsley	#24601#			OPINIONS.  MINE.  (Nobody tells me
dlindsle@blackbird.afit.af.mil		  anything anyway, so I can't possibly 
    ?? lamroN eb yhW ??			  be anybody's mouthpiece...)

Re: What should this do?

[Fred Stluka]

In article <1991Jul01.152134.16085@afit.af.mil> dlindsle@afit.af.mil (David T. 
Lindsley) writes:
>
>   subtype Index is natural; -- range 0..100;
>   type Dyn_String (Size : Index := 0) is record
>     Data : string (1..Size);
>   end record;
> 
>   S: Dyn_String;
> 
> But this still leaves me with a question.  Why does this work with a
> constrained subtype, but not with an unconstrained one?  Either results
> in the elaboration of a null array -- why is this a problem with an
> unconstrained subtype?  (Especially since NATURAL is a discrete (sub)type
> anyway...

This is a problem for many compilers for exactly the reasons 
already mentioned in previous followups.

When a default value is supplied for the discriminant of 
the record, and then an *unconstrained* object is declared,
the value of the discriminant for that object can be changed
later.

Therefore, the record is probably being allocated with enough
space to contain an array of the maximum size allowed, despite
that fact that its *initial* size is small.  When the Index type
is allowed to get as large as natural'last, this is a pretty 
large array.

Two ways to fix this:

     1)  Constrain Index to a smaller range as you did, 
         restricting the potential size of Dyn_String,
         so that less space gets allocated.

     2)  Declare S with a constraint:
               S : Dyn_String (100);
         but this is kind of pointless, because then S is
         required to *always* be exactly 100 chars long and
         is no longer a "dynamic" string.

Some if this was explained better and in more detail in previous
followups to the original question.  I suggest that you go back 
and re-read them.

--Fred
-- 
Fred Stluka                               Internet: stluka@software.org
Software Productivity Consortium          UUNet:    ...!uunet!software!stluka
2214 Rock Hill Rd, Herndon VA 22070 USA   Voice:    (703)742-7236

Re: What should this do?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!petunia!nwebre]

You might use the following program to get a glimpse of what your Ada system
is doing with mutable records. It's not completely definitive but gives a 
good clue. Sorry for the global variables - this is one off quick and
dirty.

PS to Mike Feldman - Re your question on what Alsys does in this case.
This was run on Alsys Ada on AIX/370, IBM 3090/400. It appears that they
allocate maximum space (20 bytes) and have the string bob about in it.
Good for speed, bad for space utilization


-- Check Alsys techniques for mutable records.
with text_io; use text_io;
with system;  -- Alsys version has a procedure "image" that makes
              -- addresses into strings.
procedure main is 
   subtype index is integer range 0..20;
   type rec(len : index := 0) is record
      data : string(1..len);
   end record;
   S : rec;
procedure print is
begin
   put_line("S's address is " & system.image(S'address) & " hex");
   put_line("For S.len =" & integer'image(S.len) & ',' & 
           integer'image(S'size/8) & " bytes are used."); new_line;
end print;
begin
   S := (0, "");
   print;

   S := (10,"0123456789");
   print;

   S := (20,"01234567890123456789");
   print;

   S := (0,"");
   print;
end main;

Results of execution:

S's address is 0024BAFC hex
For S.len = 0, 7 bytes are used.

S's address is 0024BAFC hex
For S.len = 10, 17 bytes are used.

S's address is 0024BAFC hex
For S.len = 20, 27 bytes are used.

S's address is 0024BAFC hex
For S.len = 0, 7 bytes are used.


Neil Webre
Cal Poly, San Luis Obispo, CA
Department of Computer Science.